[music] Каталогизация

amarok

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

амарок. он каталогизирует в базу данных.

amarok

универсальный способ это заполнить все теги. Тогда каталогизировать в плеере сможешь по алфовиту, по исполнителю/альбому/жанру и вообще как угодно

>>амарок. он каталогизирует в базу данных.

Вопрос не в том, каким проигрывателем это дело делать. Я не хочу перекладывать это на руки плейера. Меня больше волнует вопрос о каталогизации именно в каталогах, то есть средствами ФС

>>универсальный способ это заполнить все теги

я бы рад, мысль давно не дает покой. Но есть много музыки с полностью убитыми тегами (когда-то игрался с кодировками, что в итоге привело к тегам типа "######### ###") и совсем ни о чем не говорящими именами (типа Track0001.ogg)

musicbrainz можно попробовать

В амароке он есть.

да он много где есть

>>musicbrainz можно попробовать

И что? результату можно верить? Я не пробовал просто

>я бы рад, мысль давно не дает покой. Но есть много музыки с полностью убитыми тегами (когда-то игрался с кодировками, что в итоге привело к тегам типа "######### ###") и совсем ни о чем не говорящими именами (типа Track0001.ogg)

такую музыку можно удалить. не?

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

Я решаю так: в папке с музыкой папки для жанров разной музыки , но не для каждого поджанра, а для одного.  Т.е. К примеру в папке с металом у меня все виды метала, и тп. Извиняюсь, что так тупо. Сонный.

Curebok ;)

Вроде так пишется..

http://kid3.sourceforge.net/

> И что? результату можно верить? Я не пробовал просто

в 70% угадывает

Вообще, попробуй проставить все теги. Лишь затем скорми одному из трёх это дело, и пусть он тебе по директориям раскидывает.

Лично у меня всё аккуратно - сразу следил и ровно складывал =)

music/Artist/Album/Track

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

> Но есть много музыки с полностью убитыми тегами (когда-то игрался с кодировками, что в итоге привело к тегам типа "######### ###") и совсем ни о чем не говорящими именами (типа Track0001.ogg)

easytag в ряде случаев поможет.

А древовидная ФС - эт в любом случае потери информации. Только ждать ФС на основе табличных БД. Либо жёстко трахать себе мозг и тратить время на вязку сеточки из символических или жёстких ссылок.

У меня грубое приближение в виде: жанр[/поджанр]/имя/год_альбом/номер_название

> easytag

да, этот ищет по cddb

http://sourceforge.net/projects/mysqlfs/

Еще попроси добавить это в ядро, а не через фусе, бгг

>http://sourceforge.net/projects/mysqlfs/

Спасибо за ссылку!

Я теперь знаю что я прикручивать буду =)

ФС для этого не предназначена. Потому, что музыка вся разная и метаданных у нее много. iTunes каталогизирует в виде Исполнитель/Альбом/песня, так довольно удобно. Но в первую очередь надо привести в порядок тэги, это не так сложно как кажется.

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

Музыка - это хорошая модель хранения данных вообще.

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

И одновременно ФС является самым простым способом хранения. Какая-бы прослойка над ней не существовала - ФС, по видимому, будет всегда. Поэтому может быть интересен вариант, когда ФС будет не древовидна а некоторым аналогом табличной БД (да, дерево - это тоже разновидность ДБ). Разумеется вопросов здесь пока может быть больше чем ответов, как например по реализации так скажем и по переносимости.

весь музон на компе - на отдельном разделе, и строго в папках %artist%/%album% (%year%)/%tracknumber%. %title% ; и во всех файлах адекватные ID3, причем все теги с заглавной буквы и без капсов и трэша. Чистота и порядок, короче. :)

P.S. это ещё после фубара осталось. ;)

Не понимаю, при чем тут вообще ФС. У тебя есть 3 задачи: хранение музыки, доступ к музыке и организация музыки. Они вообще слабо связаны, ФС решает 1ю и частично 2ю так, чтобы было глобально, надежно и быстро. Плеет с тэгами решает частично 2ю и 3ю, чтобы форму представления можно было удобно и быстро поменять.

Вот, например, iTunes и iPod - в iTunes представление на ФС human readable, а на iPod - нет. Потому, что как бы имеется в виду, что на iPod руками не лазят и в задаче 2 человека учитывать не надо. Зачем тебе на уровне конечного пользователя знание о ФС вообще? Вот есть Aperture, в ней есть фотографии, которые хранятся со всей историей изменений, кешем превьюшек, фильтрами, метаданными и еще хрен знает чем. На ФС это представлено так, как было удобно разработчикам Aperture и мне как конечному пользователю там нечего делать. Или письма в очереди Postfix'a.

>Вопрос не в том, каким проигрывателем это дело делать. Я не хочу перекладывать это на руки плейера. Меня больше волнует вопрос о каталогизации именно в каталогах, то есть средствами ФС

Вопрос -- откуда должна браться информация о том, как раположить в ФС твои файлики? Из астрала? Нет, не подходит....

Думаем дальше. Ах да, из тегов! Жанр, исполнитель, год, альбом, номер и название трека... Что еще нужно для полного счастья?

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

Я в foobar2000 это делал, и в каких-то редакотрах тегов.

Могу предложить вот такую структуру каталогов:

Жанр/Исполнитель (композитор)/год - альбом/

Что касается имени файла, то тут могут быть варианты, начиная от самых простых (номер_трека - название_трека), заканчивая совсем уж избыточными ([Исполнитель - год - альбом] номер_трека - название трека.mp3)

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

Но если это реализовать, и если использование бд станет обыденным и рутинным, то в общем логично следующее действие - вытеснение субд на более низкий уровень - примерно на уровень файловой системы. При этом, любая операция с ФС будет автоматически операцией с БД. Конечно можно и просто иметь дополнительную прослойку, а данные держать на обычной ФС (скажем, один каталог и в нем много непонятных файлов с именами - индексами).

Что у вас за стремление, забрить всех под одну мерку? Скорость работы СУБД довольно серьезно зависит от того, что и как в ней хранится. Вот есть у тебя 1 СУБД и одно кривое приложение, которое засрало таблицы и теперь тормозит всю СУБД при своей работе. Захотел полушать музыку - и все томозит. Красота? Потом, СУБД не любят операции "удалить". Из СУБД, если что-то серьезно навернулось, сложно достать информацию. Ты предлагаешь хранить и важные и неважные данные в одной СУБД? Зачем все это? Какую задачу ты этим решаешь? Явно не задачи повышения производительности, надежности, простоты программирования, удобства администрирования, использования и отказоустойчивости.

Да, и не забываем, что микросовт говорило о единой глобальной надежной файловой ситеме-СУБД в 2000 году. Проект Юкон кажется, я был на лекции по поводу того, как это все круто будет вертеться. Воз и ныне там и я подозреваю, что не потому, что в микросовте дураки это дело проектировали, на сколько я знаю, именно этим проектом занимались не дураки.

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

Директория с музыкой/Исполнитель/[год] Альбом/ а вот с названиями треков - по-разному. когда альбом одного исполнителя, то делаю для удобства тех, кто выдергивает по несколько песен через DC++ так: Исполнитель - Номер Трека - Название Трека. Если это сборник, то: Директория с музыкой/Название сборника файлы именуются так: Номер трека - Исполнитель - Название трека. Удобно и для тек, кто выдергивает по несколько песен, без соблюдения иерархии директорий и для разных плееров, т.к. плейлист всегда складывается по порядку треков в альбоме.

Как бы через Tellico (раньше в Calc) составил базу для каждого альбома - исполнитель, год, название, стиль, на каком диске лежит.

> Скорость работы СУБД довольно серьезно зависит от того, что и как в ней хранится

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

> Потом, СУБД не любят операции "удалить". Из СУБД, если что-то серьезно навернулось, сложно достать информацию.

А эти вопросы, если действительно говорить о интеграции ФС с субд, конечно нужно решать, иначе это не выйдет со стола лаборатории.

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

А узких мест там несомненно будет даже больше чем видно навскидку. Например подключение нового накопителя.

> на сколько я знаю, именно этим проектом занимались не дураки.

Я не сомневаюсь, что в микрософте есть умные сотрудники. Но как из кривого корня вырастет прямое?

А дбфс они у беоси купили, можно уточнить у беосников оно у них уже работало или ещё не совсем.

http://en.wikipedia.org/wiki/Amarok

>о. iTunes каталогизирует в виде Исполнитель/Альбом/песня, так довольно удобно.

Для подобной каталогизации достаточно ФС. Вот скажем если бы плеер мог группировать исполнителей на основе похожести согласно last.fm...

Так понимаешь, на сколько мне известно (я не настоящий сварщик, так, мимо пробегал) недостатки и ФС и СУБД являются продолжениями их достоинств. Мне кажется, что именно хранение всего что ни есть в 1 месте - плохая идея, которая все равно при реализации вырастает в набор из нескольких инстансов нескольких СУБД разного типа, которые объеденены в один пакет для того, чтобы пользователь радовался, что все унифицировано. Как с 3х мерными интерфейсами, управлением голосом и т.п. - вроде круто, вроде где-то даже удобно, но на практике больше геморроя, чем пользы. От задачи надо отталкиваться.

Умеет. И еще много чего умеет, вроде "помеченные мной как хорошие композиции из 90х".

То есть я хотел сказать там, что iTunes на ФС так хранит. Представление же того, что ты хочешь видеть в плейлисте и как сортировать там очень гибкое.

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

juK (сухо и комфортно). Сортировка в каталоги по тегам, установка тегов по каталогам. Пакетное переименование/установка тегов. Бонус: воспроизведение музыкию ;-)

> Мне кажется, что именно хранение всего что ни есть в 1 месте - плохая идея, <...> Как с 3х мерными интерфейсами, управлением голосом и т.п. - вроде круто, вроде где-то даже удобно, но на практике больше геморроя, чем пользы. От задачи надо отталкиваться.

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

ОК, буду ждать, весьма интересно.

Тоже задавался такаим вопросом: http://www.linux.org.ru/view-message.jsp?msgid=3427745#3427972

Все вышеописанные способы всех трабл не решают

> У меня пока так: Жанр=>Группа=>Альбом

Плохой путь. Я им раньше тоже пользовался, но теперь все по другому:

music-dir/%artist/%year.%album[_comment]/%track.%artist--%title[_comment]

Если сборник, то он хранится в директории VA. Ну и да, от безымянных уродцев я избавился давно и бесповоротно.

Стиль это такое же понятие как и вкус. Мнений может быть много и зачастую они ошибочны, опять же, исполнитель может использовать несколько стилей. Поэтому наличие в пути %genre -- порочно и не нужно.

>Плохой путь. Я им раньше тоже пользовался, но теперь все по другому:

Хорошо, а вот такие ситуации:

1. Трибьют на какую-нить группу куда пихать, в VA или в группу? 2. Опять же, совместные проекты

>music-dir/%artist/%year.%album[_comment]/%track.%artist--%title[_comment]

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

> 1. Трибьют на какую-нить группу куда пихать, в VA или в группу? 2. Опять же, совместные проекты

Трибьют это что такое? Если прожект совместный, то как правило есть "главный" артист, а есть "ведомый", весьма условно, естественно. Если определить это невозможно, то в директорию, которая больше понравится (это при условии что у обоих артистов уже есть свои директории, если у обоих нет, то в VA, если есть только у одного, то в нее).

> И зачем название артиста в имени трека?

Самодостаточность и унификация. Т.е. трек может и не входить ни в какой альбом, тогда он определяется в директорию music-dir/%artist/Misc, либо music-dir/Misc, если у артиста нет своей директории (ну скажем пара треков его всего). А также если надо скопировать трек куда-либо (отослать приятелю или еще что). Так не прийдется лезть в теги, все будет понятно.

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

Это уже лишнее. Такое бывает нечасто и не особенно важно.

Да, если альбом на нескольких CD, то я делаю так:

%artist/%album/CD[1-N]/

> Трибьют на какую-нить группу куда пихать, в VA или в группу?

Нашел что это. Я бы, скорее всего, определил в VA.

Еще у меня есть директория Sondtracks, в которую определяются саундтреки к фильмам:

Soundtracks/%Year.%FilmName[_Comment]/%Track.%Artist--%Title[_Comment]

> Поэтому может быть интересен вариант, когда ФС будет не древовидна а некоторым аналогом табличной БД (да, дерево - это тоже разновидность ДБ).

"не древовидна" = +1
"табличная БД" = -1, теги и категории гибче
(вообще "древовидная ФС" -- это пример "китайской энциклопедии", а теги+категории=фолксономия)
запихни, например мартышку и умную и красивую, в 2 категории, включая новую, которой ещё не было (слили 2 старых категории в одну новую, объединение множеств