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

Мне хотелось бы видеть плеер, который умеет то, что я описывал, например, тут: 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, предложить по умолчанию индексировать по тем же полям, по каким индексируется сейчас, дать пользователю предустановленные схемы и придумать ещё много интересного и забавного...

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

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

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

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

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

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

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

Возможно, я не учёл того, что тебе хотелось бы не трогать существующий способ хранения и представления информации. Потому что если говорить о "произвольном колчестве коллекций" - то тут имеющуюся таблицу 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) таблицы, конечно же объединены индексами и констрэинтами.

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