LINUX.ORG.RU

вопрос о проигрывателях звуковых файлов


0

1

есть ли такой:

чтобы была медиабиблиотека - рейтинги отдельных аудиофайлов, плейлисты и т.п.

и самое главное!

отдельные файлы доложны идентифицироваться не по их месторасположению и имени файла, а по контенту.

то есть вот есть у меня куча файликов. решил я их переместить или стереть (но они могли остаться где-нибудь на неподключенных винтах).

медиабиблиотека должна цеплять все файлы в новом их месторасположении и автоматически ассоциировать с имеющимися записями в базе согласно контенту - можно тупо по shaX всего контента, либо используя какой-нибудь хитрый способ ускоренной идентификации не читая файл полностью.

соответственно и при проигрывании старых плейлистов должно играться то, что есть в указанных местах хранения данных, или пропускаться если такого файла не обнаружено.

ну и до кучи - возможность ассоциировать между собой несколько файлов, если они представляют собой один и тот же контент, который может заменять запись в плейлисте, если оригинального файла (одного из этой ассоциации) не обнаружено.


Библиотеку с рейтингами умеет как минимум Amarok.

медиабиблиотека должна

отсюда и ниже я ничего не понял.

aidaho ★★★★★
()
Ответ на: комментарий от aidaho

что именно непонятно?

идея проста - в плейлисты не должны записываться пути к файлам или их имена, там должны быть хэши файлов, чтобы при изменении расположения файлов можно было использовать старые плейлисты.

можно конечно записывать данные из id3 тэгов, но это не будет работать если тэгов нет или они неправильно проставлены.

то же самое относится и к рейтингам.

olegsov
() автор топика
Ответ на: комментарий от olegsov

идея проста - в плейлисты не должны записываться пути к файлам или их имена, там должны быть хэши файлов, чтобы при изменении расположения файлов можно было использовать старые плейлисты

Оно будет тормозить хлеще Непомука.

fragment
()
Ответ на: комментарий от olegsov

идея проста - в плейлисты не должны записываться пути к файлам или их имена, там должны быть хэши файлов, чтобы при изменении расположения файлов можно было использовать старые плейлисты.

Так понятно. Понятно так же, что это какое-то черезжопное решение выдуманных проблем, которое требует очень много ресурсов. В общем, согласен с предыдущими ораторами.

aidaho ★★★★★
()
Ответ на: комментарий от aidaho

выдуманных проблем

если у вас их нет, это не значит, что нет ни у кого.

типичная ситуация - приношу на работу на флешке музыку из архива, а плейлисты приходится обрабатывать скриптом для работы, и о единых рейтингах можно забыть.

требует очень много ресурсов

почти все плееры имеют функционал добавления нового расположения файлов для сканирования. вот при сканировании можно обновить привязки реальных файлов к базе. и чему тут тормозить? база будет небольшой, вполне хватит sqlite. всё что надо - обновить одно поле для объектов - новый путь к файлу.

а хэширование можно сделать ускоренное - например хэшировать только небольшую часть файла (включая id3) и размер.

а вообще, допускаю, что решение хранения рейтингов и плейлистов с ипользованием только информации из id3 тэгов тоже приемлемо, так что если подобное есть - рад буду узнать.

olegsov
() автор топика
Ответ на: комментарий от olegsov

если у вас их нет, это не значит, что нет ни у кого.

Ok.

типичная ситуация - приношу на работу на флешке музыку из архива, а плейлисты приходится обрабатывать скриптом для работы, и о единых рейтингах можно забыть.

Здесь нужен дополнительный уровень абстракции, народ использует всякие онлайн сервисы. Как вариант — unison.

Вообще всё можно, конечно, но обычно такие специфические хотелки нужно реализовывать самому. Вот это, например, вполне можно потихоньку напитонить:

а вообще, допускаю, что решение хранения рейтингов и плейлистов с ипользованием только информации из id3 тэгов тоже приемлемо, так что если подобное есть - рад буду узнать.

aidaho ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.