В интернете сейчас много поисковиков по текстам, но нет ни одного поисковика (мне по крайней мере о них ничего не известно) по картинкам, звуковым файлам, видео и др. мультимедии. Т.е. имея на руках целую или часть картинки или звукозаписи или несколько кадров фильма я не могу найти в и-нете никакой информации, относящейся к контенту. Думаю, что создание поисковика такого рода будет сравни созданию первого текстового интернет-поисковика.
Хотелось бы увидеть мнения, а также ссылки на аналоги, если таковые все-же имеются.
Как известно, 90% людей верят утверждениям, начинающимся со слов «как известно».
Здравствуйте, __gas, Вы писали:
__>В интернете сейчас много поисковиков по текстам, но нет ни одного поисковика (мне по крайней мере о них ничего не известно) по картинкам, звуковым файлам, видео и др. мультимедии.
Это от того, что ты плохо умеешь пользоваться поисковиками по текстам.
Вот, нашел за 11 секунд: http://corbis.demo.ltutech.com/en/demos/corbis/ __>Т.е. имея на руках целую или часть картинки или звукозаписи или несколько кадров фильма я не могу найти в и-нете никакой информации, относящейся к контенту. Думаю, что создание поисковика такого рода будет сравни созданию первого текстового интернет-поисковика. __>Хотелось бы увидеть мнения, а также ссылки на аналоги, если таковые все-же имеются.
1. Почитай статьи на эту тему.
2. Сформулируй парочку идей
3. Скомпонуй результаты 1 и 2 с описанием своего опыта работы
4. Полученное резюме отправь на jobs@google.com.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я-то как раз текстовыми поисковиками пользуюсь, а главное анализирую потом результаты поиска, чего и вам искренне желаю.
Попробуйте с пом. того, что вы отыскали, по имеющейся у вас копии портрета Наполеона, найти в интеренете полную информацию о нем. Если у вас получится — тогда я сразу убъю себя тапком.
S>1. Почитай статьи на эту тему. S>2. Сформулируй парочку идей S>3. Скомпонуй результаты 1 и 2 с описанием своего опыта работы S>4. Полученное резюме отправь на jobs@google.com.
PS впредь прошу топик не засорять ненужными понтами, высказывайтесь, плиз по существу.
Как известно, 90% людей верят утверждениям, начинающимся со слов «как известно».
Здравствуйте, __gas, Вы писали:
__>В интернете сейчас много поисковиков по текстам, но нет ни одного поисковика (мне по крайней мере о них ничего не известно) по картинкам, звуковым файлам, видео и др. мультимедии. Т.е. имея на руках целую или часть картинки или звукозаписи или несколько кадров фильма я не могу найти в и-нете никакой информации, относящейся к контенту. Думаю, что создание поисковика такого рода будет сравни созданию первого текстового интернет-поисковика. __>Хотелось бы увидеть мнения, а также ссылки на аналоги, если таковые все-же имеются.
Прошлым летом сам интересовался данной темой поскольку разработал алгоритм опознания мелодий, но изза трудоемкости реализации всей системы, запихнул в долгий ящик. Как бы-то ни было аналоги есть (ссылки нашел прошлым летом, так что может еще чего в мире прибавилось): http://www.owlmm.com/; зhttp://www.theengineer.co.uk/Articles/292816/Thank+you+for+the+music.htm; http://research.sun.com/spotlight/2006/2006-06-28_search_inside_music.html; http://blogs.zdnet.com/Gardner/?p=2413.
А еще прогугли программу Tunatic (http://ru.wikipedia.org/wiki/Tunatic)
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
Здравствуйте, Fiery_Ice, Вы писали:
F_I>Прошлым летом сам интересовался данной темой поскольку разработал алгоритм опознания мелодий,
В 1'000'000'000 мелодий сколько времени искать будет?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>В 1'000'000'000 мелодий сколько времени искать будет?
База из 1'000'000'000 отпечатков средних (что-то вроде простенькой попсы) 5-ти минутных милодий будет занимать около 100Тб места, вообще-то. Ну да ладно. Пускай будет 200 кластеров, на каждом из которых находится по 500Гб из этой базы, и скорость считывания 300 Мб/с. Тогда поиск будет вестись довольно долго — в худшем случае минут сорок. С такими объемами время самого опознания роли особой не играет, поскольку отпечатки "опознаются" практически прямым сравнением: если есть 20с отрывок, то необходимо найти примерно 7кб, максимально коррелирующих с искомым отпечатком, данных (это не намного более трудоемкая задача, чем поиск строки в тексте). А вот накопление 100Тб базы — как раз оччень медленный процесс.
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
F_I>Тогда поиск будет вестись довольно долго — в худшем случае минут сорок. С такими объемами время самого опознания роли особой не играет, поскольку отпечатки "опознаются" практически прямым сравнением: если есть 20с отрывок, то необходимо найти примерно 7кб, максимально коррелирующих с искомым отпечатком, данных (это не намного более трудоемкая задача, чем поиск строки в тексте).
Вообще-то есть еще такое понятие, как хэширование. Достаточно в БД хранить указатель на контент (возможно одновременно с хранением небольшого отрывка мелодии или небольшой копии изображения) + его хэш ключ (можно применять 256 или 512 битный хэш). Тогда из искомой мелодии получаем хэш ключ и просто индексируем его в нашей БД. Это, заметьте, уже порядка нескольких секунд, особенно, если для поиска использовать многопроцессорную систему (задача ведь легко распараллеливается, т.к. по сути это бинарный поиск). Но вообще говоря это очень примитивный подход. У меня появляются более реалистичные идеи поиска по мультимедии. Например, можно мелодии разбивать на определенные составляющие, как то: ритм, частотную характеристику и т.п. далее в искомой мелодии выделять тот же набор параметров и начинать поиск по соответствующей БД с использованием хэша. Можно искать мелодии не целиком по контенту, а по отдельным кускам (например, 3 секунда начала, 5 секунд середина, 2-3 секунды конец). Соответственно можно выдавать похожие мелодии, у которых могут совпадать не все части с искомой мелодией — это уже будет поиск с произвольной релевантностью. Для картинок можно строить гистаграммы, а также выделять основные кластеры изображения по которым так же осуществлять неточный поиск в БД. Причем, такой поиск не будет занимать ощутимого времени.
F_I>А вот накопление 100Тб базы — как раз оччень медленный процесс.
накапливать 100Тб базы, разумеется не придется — база будет содержать в лучшем случае небольшие отрывки и ссылки на индексируемые ресурсы. Но, конечно сама индексация может быть долгим процессом. Но то же утверждение верно и для текстовых поисковиков. Причем, если вдуматься объем БД для полнотекстного поиска может даже превышать объем БД для поиска музыки, т.к. традиционно в интернете преобладает текстовый контент. И потому объемы текста весьма велики.
Как известно, 90% людей верят утверждениям, начинающимся со слов «как известно».
Здравствуйте, Fiery_Ice, Вы писали:
F_I>База из 1'000'000'000 отпечатков средних (что-то вроде простенькой попсы) 5-ти минутных милодий будет занимать около 100Тб места, вообще-то.
Это не проблема.
F_I>Ну да ладно. Пускай будет 200 кластеров, на каждом из которых находится по 500Гб из этой базы, и скорость считывания 300 Мб/с.
Линейный поиск... как все запущенно.
Должен быть в худшем случае log(N).
F_I>Тогда поиск будет вестись довольно долго — в худшем случае минут сорок.
Должно быть единици секунд в худшем случае.
А большенство запросов должны отрабатывать сильно быстрее секунды.
F_I>С такими объемами время самого опознания роли особой не играет, поскольку отпечатки "опознаются" практически прямым сравнением: если есть 20с отрывок, то необходимо найти примерно 7кб, максимально коррелирующих с искомым отпечатком, данных (это не намного более трудоемкая задача, чем поиск строки в тексте).
Ну посмотри с какой скоростью тотже Яндекс строки в тексте ищет...
F_I>А вот накопление 100Тб базы — как раз оччень медленный процесс.
Ну ты же не на один день собрался поисковик запускать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Не хочу показаться очень умным, но разве эта задача не сводится полностью к классическим "тяжелым" AI проблемам (speech/object/music recognition, etc), по которым есть куча исследований и информации. Приделать сверху поиск не представляет никакой сложности. Мне кажется, что на это и намекал Sinclair...
Здравствуйте, __gas, Вы писали:
__>Вообще-то есть еще такое понятие, как хэширование...
Ну да, и каждую новую копию песни, сжатую другим кодеком, или имеющую малейшие шумовые искажения считать новой...
__>У меня появляются более реалистичные идеи поиска по мультимедии. Например, можно мелодии разбивать на определенные составляющие, как то: ритм, частотную характеристику и т.п. далее в искомой мелодии выделять тот же набор параметров и начинать поиск по соответствующей БД с использованием хэша. Можно искать мелодии не целиком по контенту, а по отдельным кускам (например, 3 секунда начала, 5 секунд середина, 2-3 секунды конец). Соответственно можно выдавать похожие мелодии, у которых могут совпадать не все части с искомой мелодией — это уже будет поиск с произвольной релевантностью.
-Можно и разбивать. А можно и в объединенном виде использовать. Дело вкуса.
-По поводу кусков:
а)нет никаких гарантий, что в самой базе находятся полные версии композиций
б)5с гдето в середине могут оказаться практически идентичными у тысяч "композиций" (нынешняя эстрада не блещет оригинальностью)
-если использовать поэлементное сравнение, то результат точнее (тем более что элементов-то не так и много)
__>накапливать 100Тб базы, разумеется не придется — база будет содержать в лучшем случае небольшие отрывки и ссылки на индексируемые ресурсы.
Прийдется: отпечаток каждого обработанного звукового файла должен хранится в базе, а будит-ли он сопоставлятся со ссылкой — дело десятое (главное теги хранить — пользователь ведь именно их хочет узнать, отправляя на обработку свой файл)
Здравствуйте, WolfHound, Вы писали:
WH>Линейный поиск... как все запущенно. WH>Должен быть в худшем случае log(N).
Согласен, что запущено. Но тратить время на продумывание и устранение этой проблемы у меня нет желания (по крайней мере сейчас) — и по-важнее дела есть. В конце концов, на реализацию этой системы, у меня уйдет хз сколько времени, а в природе уже и готовые аналоги есть...
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
Здравствуйте, WolfHound, Вы писали:
WH>Линейный поиск... как все запущенно. WH>Должен быть в худшем случае log(N).
Согласен, что запущено. Но тратить время на продумывание и устранение этой проблемы у меня нет желания (по крайней мере сейчас) — и по-важнее дела есть. В конце концов, на реализацию этой системы, у меня уйдет хз сколько времени, а в природе уже и готовые аналоги есть...
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
Здравствуйте, novitk, Вы писали:
N>Не хочу показаться очень умным, но разве эта задача не сводится полностью к классическим "тяжелым" AI проблемам (speech/object/music recognition, etc), по которым есть куча исследований и информации. Приделать сверху поиск не представляет никакой сложности. Мне кажется, что на это и намекал Sinclair...
Я бы не относил данную задачу к AI-проблемам, (в отличии от задачи понимания (машиной) смысла услышанных звуков, или "прочитанного" текста). Тут как и с человеческим ухом — оно только преобразовывает звук в такую форму, с которой мозгу проще всего работать, и которая занимает как можно меньше места без потери ключевых данных.
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
__>>Вообще-то есть еще такое понятие, как хэширование... F_I>Ну да, и каждую новую копию песни, сжатую другим кодеком, или имеющую малейшие шумовые искажения считать новой...
Как-то ты сам себе противоречешь. Не ты ли постом выше собирался побайтово сравнивать файл с базой? Насчет кодеков — не уверен, что их бесчисленное множество, так что тут просто вопрос полноты индексации.
F_I>-По поводу кусков: F_I>а)нет никаких гарантий, что в самой базе находятся полные версии композиций
А это и не нужно, если сравнивать файл характерными частями (отдельный вопрос об их выборе для конкретной композиции), то полные версии не нужны никогда
F_I>б)5с гдето в середине могут оказаться практически идентичными у тысяч "композиций" (нынешняя эстрада не блещет оригинальностью)
Могу, конечно, тогда пользователь просто увидит менее релевантные ссылки. Кстати то же замечание справедливо и для текстового поиска, т.к. тексты еще менее оригинальны.
F_I>-если использовать поэлементное сравнение, то результат точнее (тем более что элементов-то не так и много)
Опять противоречие с твоим первым замечанием
F_I>Прийдется: отпечаток каждого обработанного звукового файла должен хранится в базе, а будит-ли он сопоставлятся со ссылкой — дело десятое (главное теги хранить — пользователь ведь именно их хочет узнать, отправляя на обработку свой файл)
Утверждение не обосновано. Зачем хранить у себя в БД то, что и так доступно по сети? А если по сети не доступно, то и индексация по такому битому ресурсу не нужна.
F_I>Согласен, что запущено. Но тратить время на продумывание и устранение этой проблемы у меня нет желания (по крайней мере сейчас) — и по-важнее дела есть. В конце концов, на реализацию этой системы, у меня уйдет хз сколько времени, а в природе уже и готовые аналоги есть...
А вроде никто и не заставляет тебя тратить свое драгоценное время. А насчет готовых аналогов я бы сильно поспорил — их нет ИМХО, или они хорошо скрываются.
Как известно, 90% людей верят утверждениям, начинающимся со слов «как известно».
Здравствуйте, __gas, Вы писали:
__>>>Вообще-то есть еще такое понятие, как хэширование... F_I>>Ну да, и каждую новую копию песни, сжатую другим кодеком, или имеющую малейшие шумовые искажения считать новой... __>Как-то ты сам себе противоречешь. Не ты ли постом выше собирался побайтово сравнивать файл с базой? Насчет кодеков — не уверен, что их бесчисленное множество, так что тут просто вопрос полноты индексации. F_I>>-если использовать поэлементное сравнение, то результат точнее (тем более что элементов-то не так и много) __>Опять противоречие с твоим первым замечанием
-Противоречий нет: ты предлагаешь хранить и использовать при обработке запросов сам звук (возможно даже в сжатом виде), а я говорю про "отпечаток звука": прежде чем попасть в базу звук преобразовывается к такому виду, в котором различия типа измененной громкости/скорости/тона роли не играют (разумеется эти изменения должны быть как можно более равномерными для всего фрагмента), а дополнительные шумы (вроде шипения старой пластинки) хоть и портят картину, но не настолько чтобы сравнение давало неверные результаты. Чем сложнее звуковая запись, тем больше размер опечатка ([14 — 250]кб на 5мин песни). Прежде чем начать поиск, производится расчет отпечатка искомого звукового фрагмента.
-Я говорю не про "побайтное сравнение звукового файла", а про "поэлементное сравнение отпечатков".
F_I>>-По поводу кусков: F_I>>а)нет никаких гарантий, что в самой базе находятся полные версии композиций __>А это и не нужно, если сравнивать файл характерными частями (отдельный вопрос об их выборе для конкретной композиции), то полные версии не нужны никогда
А если у пользователя отрывок, в который не входят эти самые характерные части (я так понял, ты предлагаешь использовать при сравнении например: 5с начиная с 30-й, 14с начиная с 67-ой, и т.д?). Для поиска пользователю достаточно иметь 15-25с отрывок.
F_I>>Прийдется: отпечаток каждого обработанного звукового файла должен хранится в базе, а будит-ли он сопоставлятся со ссылкой — дело десятое (главное теги хранить — пользователь ведь именно их хочет узнать, отправляя на обработку свой файл) __>Утверждение не обосновано. Зачем хранить у себя в БД то, что и так доступно по сети? А если по сети не доступно, то и индексация по такому битому ресурсу не нужна.
Если не хранить отпечаток в базе, то как по-твоему сработает связь [отпечаток-ссылка(и)]? Или прикажешь по каждому запросу пользователя (запрос — это звуковой фрагмент, а ответ — название, и, возможно, ссылки) начинать скачивать музыку по всем ссылкам и обрабатывать ее по стомильйонов-дцатому разу?
__>А насчет готовых аналогов я бы сильно поспорил — их нет ИМХО, или они хорошо скрываются.
— Tunatic, по крайней мере, что-то опознает (из микрофона кстати)
— Я читал про сервис, предоставляемый одним из телефонных операторов (или в США, или в какой-то европейской стране — не помню): слышишь рядом на улице классную песню, а названия не знаешь; звонишь с мобильника на определенный номер, музыка у них пишется (со всеми шумами, и урезаностью частотного диапазона); через пару минут получаешь смс с названием песни и именем исполнителя. Стоит недорого. Вроде-как популярностью пользуется.
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
Здравствуйте, Fiery_Ice, Вы писали:
F_I>Я бы не относил данную задачу к AI-проблемам, (в отличии от задачи понимания (машиной) смысла услышанных звуков, или "прочитанного" текста).
Это просто принятая классификация. Насколько она удачна спорить не хочу.
> Тут как и с человеческим ухом — оно только преобразовывает звук в такую форму, с которой мозгу проще всего работать, и которая занимает как можно меньше места без потери ключевых данных.
Не вижу аналогий. Человеческое ухо это Д-А конвертер, проблема человечеством в принципе решенная. В отличие от сложных Д-Д про которые здесь речь.
Еше раз повторюсь — поиск здесь просто следствие решение более фундаментальной проблемы, в которую вложены громадные средства и усилия. Например в случае музыки, проблема именно в WAV-to-SMF трансформере, а не в создании интернет-поиска при его наличие.
[...] __>Попробуйте с пом. того, что вы отыскали, по имеющейся у вас копии портрета Наполеона, найти в интеренете полную информацию о нем. Если у вас получится — тогда я сразу убъю себя тапком.
[...]
... по пикселю найти фотографию ? ... я тоже хочу такой поисковик
Здравствуйте, Othello, Вы писали:
__>>Попробуйте с пом. того, что вы отыскали, по имеющейся у вас копии портрета Наполеона, найти в интеренете полную информацию о нем. Если у вас получится — тогда я сразу убъю себя тапком. O>... по пикселю найти фотографию ? ... я тоже хочу такой поисковик
Ну по пикселю ты конечно ничего не найдешь. Но по картинке 100х100 картинку 1000х1000 найти вполне реально.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Othello, Вы писали:
O>>... по пикселю найти фотографию ? ... я тоже хочу такой поисковик WH>Ну по пикселю ты конечно ничего не найдешь. Но по картинке 100х100 картинку 1000х1000 найти вполне реально.
гм — мне кажется для таких вещей время не настало — если это в глобальном масштабе брать — то на самом деле — чтото революционное нужно.
Здравствуйте, Othello, Вы писали:
O>гм — мне кажется для таких вещей время не настало — если это в глобальном масштабе брать — то на самом деле — чтото революционное нужно.
Есть алгоритм для поиска похожих картинок за log(n) от размера индекса.
Причем очень хорошо ложится на кластер. С файловером, балансировкой итд итп
Как именно это делается расказывать не буду.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, __gas, Вы писали:
__>В интернете сейчас много поисковиков по текстам, но нет ни одного поисковика (мне по крайней мере о них ничего не известно) по картинкам, звуковым файлам, видео и др. мультимедии. Т.е. имея на руках целую или часть картинки или звукозаписи или несколько кадров фильма я не могу найти в и-нете никакой информации, относящейся к контенту. Думаю, что создание поисковика такого рода будет сравни созданию первого текстового интернет-поисковика. __>Хотелось бы увидеть мнения, а также ссылки на аналоги, если таковые все-же имеются.
Недавно попал вот на такую статейку в Википедии. Теперь хоть знаю, как оно правильно называется и кто еще этим занимается
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
. Ну да ладно. Пускай будет 200 кластеров, на каждом из которых находится по 500Гб из этой базы, и скорость считывания 300 Мб/с. Тогда поиск будет вестись довольно долго — в худшем случае минут сорок. С такими объемами время самого опознания роли особой не играет, поскольку отпечатки "опознаются" практически прямым сравнением: если есть 20с отрывок, то необходимо найти примерно 7кб, максимально коррелирующих с искомым отпечатком, данных (это не намного более трудоемкая задача, чем поиск строки в тексте). А вот накопление 100Тб базы — как раз оччень медленный процесс.
