убрать эту ссылочку и просто отображать кастомные тэги вместе с остальными
добавить кнопку "+" чтобы при нажатии на нее можно было добавить свой тэг и задать его полю свое значение.
главное заставить понимать эти метки другим приложениям
Я привёл ссылку с описанием использования тэгов дат такими программами как Taglib, ffmpeg, kid3Как вы сами обозначили, расширенная поддержка существует в программах, которые и предназначены для обработки файлов.
Пренебрегают этими тэгами в основном стриминговые сервисы (включая в этом смысле iTunes).
Никому не важно как обстоят дела с тэгами. увы.Не то чтобы совсем не важно. Но вы правильно заметили, что сейчас эпоха потребления, поэтому потребитель будет на то, что делают другие "игроки рынка". Если они распространяют "плохие" файлы, то не каждый пользователь захочет их исправлять.
может чтобы снять все вопросы по добавлению тех или тегов сделать как в foobar
а структуру данных вы как будете определять там?На всех типах файлов не проверял, но как то у всех не было вопросов.
Более того, даже если так сделать - в плеере-то эти теги не смогут быть использованы, ибо он них ничего не знаетВопрос по отображению или сортировке / группировке? В указанном проигрывателе тоже вроде нет...
Смысл с этих кастомных тегов, если проигрыватель не умеет ими пользоваться?Я всё понимаю, что возникают определённые "проблемы", но их придётся решать через присвоение добавленным тегам определённых значений и с ними работать проигрывателю. Иначе в будущем так и будут возникать предложения и вопросы по добавлению тех или иных новых тегов.
Если писать известный плееру мультитэг, хотя бы группировка и сортировка будет работать
Иначе в будущем так и будут возникать предложения и вопросы по добавлению тех или иных новых тегов
Приведу в качестве примера группировку по созданному / добавленному тегу <RADIO STATION> (Радиостанция) в foobar.
А можно его, к примеру, в ID3v2 сохранить? И так, чтобы этим тегом еще другие программы могли пользоваться?Насколько я понимаю, если структура данных для определённых аудио файлов позволяет сохранять "дополнительные" теги, то они сохраняется в тегах файла. Если это выходит за рамки "стандарта", то дополнительные теги, как и основные поля, могут сохраняться в БД внешних тегов.
Насколько я понимаю, если структура данных для определённых аудио файлов позволяет сохранять "дополнительные" теги, то они сохраняется в тегах файла. Если это выходит за рамки "стандарта", то дополнительные теги, как и основные поля, могут сохраняться в БД внешних тегов.
В дополнительные теги оно писаться НЕ ДОЛЖНО.
Тем не менее в некоторые аудио файлы они прописываются.
Проверил на "чистом" foobar2000:
Этот же файл в Mp3tag:
Я говорю не про то, что не должны прописываться, я говорю про то, что должны записываться в правильное поле, а не в дополнительное. Именно поэтому для каждого стандартного поля нужно делать поддержку на стороне приложения.Что значит правильное поле?
Что значит правильное поле?А что дальше с этим полем смогут сделать другие плееры? Особенно когда тег останется исключительно в базе фубара
Создал дополнительное абстрактное поле в теге <ABC> = ТЕСТ:
Особенно когда тег останется исключительно в базе фубара
Давно можно было бы встроить в редактирование остальных полей, как сделано в "неизвестные поля".Это более универсальное решение вместо сабжевого предложения. При этом, будет различие в "массовых" (распространённых) тегах и тех, которые в большинстве случаев будут доступны только спец. софту.
Тоже не совместимость?
Что значит правильное поле?
Я поэтому и говорю, что нельзя просто так взять и писать тег в виде пары ключ+значение.
Для удовлетворения собственного любопытства, взял файл формата *.m4a, прописал ещё один дополнительный тег <ABRACADABRA>.Вам про Фому, а вы про Ерёму
Если во всех тегах написать RELEASETIME, как на вашей картинке, то только в одном теге это поле будет стандартным, а во всех остальных - кастомным и, по сути, бесполезным
Не пойму, почему бесполезным. Если поле (стандартное или кастомное) с произвольным именем прописывается и сохраняется в теге файла, почему с ним нельзя работать в дальнейшем?Потому что это костыль
Если поле (стандартное или кастомное) с произвольным именем прописывается и сохраняется в теге файла, почему с ним нельзя работать в дальнейшем?
Нормальный плеер будет поле "дата_релиза" записывать и считывать в соответствии со стандартом конкретного тега, а не по фантазии пользователя
Ну вот на заводе пропишут теги согласно стандарту, а плеер будет ждать кастомное, и стандартное не увидит, ведь он не знает, как оно называется.
Надеюсь мы говорим про программные проигрыватели? Как я понимаю, стандартные поля выводятся согласно стандарта, а дополнительные в отдельном поле, как в Mp3tag. Что бы их увидеть - отдельное окно, в foobar'е дополнительные теги располагаются в окне ниже стандартных. В данном проигрывателе можно проделывать операции (сортировка, группировка и т.п.) с ЛЮБЫМИ именами дополнительных тегов.
Если нет желания или времени этим заниматься, то и не надо заставлять себя... :)
ReleaseDate, из которого пошла исходная дискуссия, не относится к дополнительным тегам. Это СТАНДАРТНОЕ поле, и обрабатываться должно именно так.
Тема уже другая и меня больше интересуют ДОПОЛНИТЕЛЬНЫЕ теги (с произвольными именами) и возможность дальнейшей работы с ними.
Ну тогда голосуйте
Где вообще гарантия, что потом это "кастомное поле" не вылезет в какой-нибудь баг?
Если какая-то спецификация поддерживает добавление кастомных полей...
в отличие от AIMP:
А разве в редакторе появятся новые поля или в этом же окне возникнет отдельная вкладка или кнопка (наподобие OLE-объекта) для доступа к ним?
Ну, что ж, сами напросились: строго говоря, раз в AIMP`е нет никаких средств для создания этих самых подключаемых модулей (или даже банального компилятора/сборщика/компановщика, уже пофиг на «хотя бы текстовый» редактор), то, получается, тоже, да.
А мне всего лишь нужен был ответ на вопрос «как станут доступны "пользовательские" поля в редакторе меток?»…