Редактирование и добавление нестандартных полей тегов

[7755]

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

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

Предлагаю:
1.убрать эту ссылочку и просто отображать кастомные тэги вместе с остальными
2.добавить кнопку "+" чтобы при нажатии на нее можно было добавить свой тэг и задать его полю свое значение.


Простой пример. Я сконвертировал в том же аимпе в конверторе кучу файлов wav в формат ogg, я хочу их использовать на андроид смартфоне как рингтоны, всем ogg надо добавить тэг "ANDROID_LOOP" с указанием значения "true".
Тогда мелодия будет проигрываться бесконечно при звонке.

Понимаю что частный случай, но просто для примера. Есть разные кастомные тэги, некоторым помогают ориентироваться в фонотеке.

Например тэг "encoder"

рингтон с тэгами во вложении

[Artem]

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

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

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

Это можно сделать, как в раз в том диалоге "неизвестные поля".
Голосуйте

[«G-Li†ch»]

Так речь же не о только тексте, а о байтах в целом, т.е. прямо в "hex" области вписывать нужные значения (для ID3 особенно).
А для Vorbis я уже лет 12 жду возможности вписывать пользовательские метки AIMP`ом…
И плевать, как проигрывать их будет их определять, т.к. предназначены для специальных приложений (или каких-нибудь игр)…

[Artem]

главное заставить понимать эти метки другим приложениям

Это самая главная проблема. Если нет стандарта - работать не будет.

[Алексей Долматов]

Примечание: это и последующие сообщения перенесены из предложения ReleaseDate, поэтому повествование начинается немного отрывочно.
Невозможно вместить всё, чтобы оно было совместимо везде. На примере тех же каверов. AIMP показывает основную картинку. Где-то может показываться дополнительная (задник компакт-диска). Есть редакторы тегов, где вообще можно кучу картинок встроить. Только вот смысл записывать кучу данных, если их нельзя будет прочитать/отредактировать или они будут портить файл (мешать воспроизведению, конвертированию).

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

Я привёл ссылку с описанием использования тэгов дат такими программами как Taglib, ffmpeg, kid3

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

Пренебрегают этими тэгами в основном стриминговые сервисы (включая в этом смысле iTunes).

Никому не важно как обстоят дела с тэгами. увы.

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

[MCW]

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

[Artem]

может чтобы снять все вопросы по добавлению тех или тегов сделать как в foobar

а структуру данных вы как будете определять там? Для OGG/FLAC такое еще прокатит - там в тегах простые пары вида Key=Value, а вот для MP3/MP4 уже нет - там у полей более сложная структура. Более того, даже если так сделать - в плеере-то эти теги не смогут быть использованы, ибо он них ничего не знает

[MCW]

а структуру данных вы как будете определять там?

На всех типах файлов не проверял, но как то у всех не было вопросов.

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

Вопрос по отображению или сортировке / группировке? В указанном проигрывателе тоже вроде нет...

[Soolo]

Смысл с этих кастомных тегов, если проигрыватель не умеет ими пользоваться?
Если писать известный плееру мультитэг, хотя бы группировка и сортировка будет работать

[MCW]

Смысл с этих кастомных тегов, если проигрыватель не умеет ими пользоваться?

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

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

Приведу в качестве примера группировку по созданному / добавленному тегу <RADIO STATION> (Радиостанция) в foobar.

[Artem]

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

А как иначе? Серебряной пули тут нет.

Приведу в качестве примера группировку по созданному / добавленному тегу <RADIO STATION> (Радиостанция) в foobar.

А можно его, к примеру, в ID3v2 сохранить? И так, чтобы этим тегом еще другие программы могли пользоваться?

[MCW]

А можно его, к примеру, в ID3v2 сохранить? И так, чтобы этим тегом еще другие программы могли пользоваться?

Насколько я понимаю, если структура данных для определённых аудио файлов позволяет сохранять "дополнительные" теги, то они сохраняется в тегах файла. Если это выходит за рамки "стандарта", то дополнительные теги, как и основные поля, могут сохраняться в БД внешних тегов.

Только ради бога, как я считаю, не надо полностью переходить на sqlite, как это сделали в foobar v.2,0+. Наблюдается постоянное "пожирание" дискового пространства за счёт разрастания БД, поэтому данными версиями (foobar v.2,0+) не пользуюсь вообще. Использую foobar v.1,6 с компонентом foo_external_tags, который позволяет выборочно сохранять "нестандартные" теги во внешней БД (external-tags.db).

Примеры онлайн-плейлистов:

Без дополнительных полей в тегах (отображаются поля содержащиеся в тегах)



Если требуются дополнительные поля тегов, то они сохраняются во внешней БД

[Artem]

Насколько я понимаю, если структура данных для определённых аудио файлов позволяет сохранять "дополнительные" теги, то они сохраняется в тегах файла. Если это выходит за рамки "стандарта", то дополнительные теги, как и основные поля, могут сохраняться в БД внешних тегов.

О чем и речь. В дополнительные теги оно писаться НЕ ДОЛЖНО.

[MCW]

В дополнительные теги оно писаться НЕ ДОЛЖНО.

Тем не менее в некоторые аудио файлы они прописываются.

Проверил на "чистом" foobar2000:

Этот же файл в Mp3tag:

[Artem]

Тем не менее в некоторые аудио файлы они прописываются.

Проверил на "чистом" foobar2000:

Этот же файл в Mp3tag:

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