каталогизация по произвольным полям

[GoogleCodeExporter]

Хотелось бы заявить свой первый и сразу 
глобальный запрос функционала.
Предлагаю начать обсуждение.

Мне хотелось бы видеть плеер, который умеет 
то, что я описывал, например, 
тут:
http://www.linux.org.ru/view-message.jsp?msgid=3687113

Поскольку такого никто не умеет, я хочу 
попросить разработчиков 
реализовать это. 

Прошу реализовать такую возможность: при 
добавлении файлов в коллекцию 
сканировать не стандартный набор полей 
метаинформации, а произвольный. 
Например, для современной музыки 
действительно основными используемыми 
тегами являются atrist/album/title. В то время, как 
уже для музыки из 
советских фильмов этого не достаточно: там 
отдельно нужно хранить 
композитора, автора слов, исполнителя 
музыки, исполнителя голоса + 
возможно какую-то ещё информацию. А для 
классики так и более широкий 
спектр тегов потребуется: композитор, 
исполнитель, дирижёр, оркестр, дата 
сочинения, дата исполнения, не говоря уже о 
том, что даже вот это:

Box 16: German Operas
CD 11: Mozart: Complete Edition 
Composer: Wolfgang Amadeus Mozart (1756 - 1791)
Composition: Die Zauberflöte, K.620
Act 2
Dialog "Tamino, wollen wir nicht speisen?"
Artist: Hans Jörn Weber, Elke Wieditz, Mikael Melbye
Orchestra: Staatskapelle Dresden
Conductor: Sir Colin Davis

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

Стандарт id3v2.4 предлагает очень большое 
количество тегов для подобного 
извращения ( http://www.id3.org/id3v2.4.0-frames ), в том 
числе 
произвольных тегов. Одновременно vorbis.comment 
вообще кроме произвольных 
тегов не имеет жёстко прошитых. Можно 
попробовать найти какие-нибудь более 
или менее стандартные таблицы 
соответствия (часть уже есть, те же artist/
album/title) между id3 и vorbis.comment, предложить по 
умолчанию 
индексировать по тем же полям, по каким 
индексируется сейчас, дать 
пользователю предустановленные схемы и 
придумать ещё много интересного и 
забавного...

Original issue reported on code.google.com by nomen.in...@gmail.com on 1 Jun 2009 at 5:51

[GoogleCodeExporter]

Вопрос конечно интересный. Главная 
проблема: как в коллекции будут уживаться 
попса и
матёрая классика? У них же предполагаются 
почти непересекающиеся множества данных.

На вскидку могу предложить в набор 
существующих полей (там около семи полей из 
тегов)
проецировать произвольные теги id3v2.4 или ogg. 
Если этого мало, то надо думать дальше.

Original comment by drmoriar...@gmail.com on 2 Jun 2009 at 10:14

• Changed state: Accepted

[GoogleCodeExporter]

Второй вариант на вскидку. Реализовать 
дополнительную схему. Основная схема
заполняется как есть (для попсы). 
Дополнительная задаётся произвольным 
набором
упорядоченных полей. И сделать два режима 
плейлиста, для отображения основного 
набора
и дополнительного. Единственно что, не 
представляю пока как сделать удобную 
выбиралку
в коллекции по расширенному набору.

Original comment by drmoriar...@gmail.com on 2 Jun 2009 at 11:29

[GoogleCodeExporter]

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

> Единственно что, не представляю пока как 
сделать удобную выбиралку в коллекции по 
расширенному набору.

Если говорить про удобство для 
пользователя и хотеть сохранить 
представление, которое 
есть сейчас, то можно, наверно, сделать так:
1. там, где мы задаём поля, по которым вести 
каталогизацию, позволить расставить 
галочки "узел" (или как-нибудь так) напротив 
нескольких полей
2. после сканирования каталогов или 
пересканирования файлов на вкладке 
"коллекция" 
отображаются кнопки нодов/узлов/however, но 
пока что в виде надписей. Поведение этих 
кнопок такое же, как сейчас у genre/artist/album/track
3. правая кнопка мыши или дополнительное 
меню на этих кнопках / в этой вкладке 
позволяет задать иконки 
узлам/нодам/как_их_там и отсортировать их в 
произвольном 
прорядке (создаёт видимость иерархичности)

// 4. возможно - было бы интересно, но не факт, 
что вообще реализуемо - объединение 
нескольких нодов в одну кнопку. Наверно, 
всё-таки ненужно, придумать полезного 
примера 
не смог.

Original comment by nomen.in...@gmail.com on 2 Jun 2009 at 1:20

[GoogleCodeExporter]

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

sqlite> .schema Song
CREATE TABLE Song (ID integer primary key autoincrement, File varchar(250), 
Track 
integer, Title varchar(200), Artist integer, Album integer, Genre integer, Year 
integer, Comment varchar(200), Length varchar(20), Rating integer);

придётся прекроить. И я полагаю, что при 
любых изменениях её придётся перекраивать, 
либо делать другую таблицу рядом.

Поэтому предлагаю сразу её перекроить. Я 
вообще привык, что у нас (у меня на работе) 
подобная информация разбивается на 
несколько таблиц. Таблица номер 1 - словарь. 
Что-
то типа такого:

sql++> desc dict;
+-------------+----------+---------------+
| Name        | Null?    | Type          |
+-------------+----------+---------------+
| DICT_ID     | NOT NULL | NUMBER(22)    |
| TYPE_ID     | NOT NULL | NUMBER(22)    |
| FORMAT_ID   | NOT NULL | NUMBER(22)    |
| ATTRIBUTE   | NOT NULL | VARCHAR2(255) |
| CTL_TYPE    |          | VARCHAR2(255) |
| DFL_VAL     |          | VARCHAR2(255) |
| DESCRIPTION |          | VARCHAR2(255) |
+-------------+----------+---------------+
7 rows in set (0.051 secs)

нам, конечно, ctl_class и def_val не нужны, но смысл 
понятен. Можно сделать поля 
DICT_ID, VORBIS_COMMENT, ID3_FIELD, DESCRIPTION или что-то 
подобное.
Вторая таблица - основные данные, которые 
нужны при любом способе каталогизации. 
Например, это имя файла, номер коллекции и 
уникальный идентификатор (id). Третья 
таблица - это, соответственно, паспорт. 
Например:
desc SERVICES_EXT;
+-----------------+----------+---------------+
| Name            | Null?    | Type          |
+-----------------+----------+---------------+
| SERVICES_EXT_ID | NOT NULL | NUMBER(22)    |
| SERVICE_ID      | NOT NULL | NUMBER(22)    |
| DICT_ID         | NOT NULL | NUMBER(22)    |
| VALUE           |          | VARCHAR2(255) |
| DATE_BEG        | NOT NULL | DATE(7)       |
| DATE_END        |          | DATE(7)       |
+-----------------+----------+---------------+
6 rows in set (0.006 secs)
таблицы, конечно же объединены индексами и 
констрэинтами.

Original comment by nomen.in...@gmail.com on 2 Jun 2009 at 1:37

[GoogleCodeExporter]

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

Original comment by drmoriar...@gmail.com on 3 Jun 2009 at 6:43