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

[Artem]

Тема уже другая и меня больше интересуют ДОПОЛНИТЕЛЬНЫЕ теги (с произвольными именами) и возможность дальнейшей работы с ними.

Ну тогда голосуйте

[MCW]

Ну тогда голосуйте

Уже давно это сделал.

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

Где вообще гарантия, что потом это "кастомное поле" не вылезет в какой-нибудь баг? Например, в проводнике Windows будут читаться метаданные и не поймут отсебятины, а потом весь проводник зависать или падать. Или без критичных ситуаций, но, банально, потеря данных при конвертации в другой формат. Хорошо, если только лишние данные сотрутся. Но, ведь бывало, что неправильные теги (несколько стандартов, неправильный порядок) приводили к потери части композиции, потому что ожидался конец файла, а оказалось какая-то смесь данных. Хорошо, если на стороне плеера или конвертера это можно пофиксить. А, если это кажется не развивающийся продукт, аля винамп.
Вот и получается, что либо следует правилам создателей форматов и записи метаданных, или пишем всё подряд и рискуем получить по шапке, если что-то где-то не будет правильно работать, потому что такого в файле не должно быть.
Я вижу, что вам информация о позиции администраторов предоставлена. Всё остальное переливание из пустого в порожнее. Не вижу смысла дальше обсуждать то, что уже обсудили с разных сторон.
То, что какие-то программы делают по своему не значит необходимость следовать мнению (решению) их разработчиков. Оно может быть и неправильным, потому что разработчики пошли на поводу у пользователей, не учитывая правила создателей спецификаций.
Если какая-то спецификация поддерживает добавление кастомных полей, то это вполне реализуется в рамках моего предложения. Где фиксированный список возможных полей, там только они показываются-редактируются, остальное в неизвестных полях без возможности редактировать (редактируйте тем, что эти поля создало). Причём, количество полей для разных форматов и типов тегов может быть разное. Где допускается запись посторонних данных, то они записываются куда полагается. Вопрос их использования плеером, фонотекой под сомнением.
Однако, это требует внедрение алгоритма анализа файлов. Не исключено, что для облегчения веса компонентов плеера, часть кода надо будет вынести в отдельный файл. Это определить не берусь, т.к. вне моих знаний и возможностей.

[MCW]

Где вообще гарантия, что потом это "кастомное поле" не вылезет в какой-нибудь баг?

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

Если какая-то спецификация поддерживает добавление кастомных полей...

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

[«G-Li†ch»]

У Winamp такой проблемы никогда не было — там "испокон веков" всё

Вон, конвертеры из AIMP`а всё ж перенесли в подключаемые модули, так давайте уже и tag-parser`ы туда же перенесём. Давно хочу подобное для трекерных модулей, Creative Music File и Standard MIDI File (а может и уже ныне существующего .MIDI2… эти падлы всё равно в XML всё запихнули гады, ох как я его ненавижу…), я не удивлюсь, если даже к самой древнющей версии винампа смогут прикрутить поддержку MIDI 2.0 (причём не только прочитать мета-данные, но и в принципе воспроизвести такой файл)…
Но история с метаданными MIDI 2.0 — это уже вообще отдельная МЕГА-тема, к примеру, описывание каждого используюегося звука в ударнике, чтоб "целевой" инструмент внутри себя мог хоть что-то похожее подобрать — это ж гигантский массив атрибутов и значений для каждого из них, слишком велика вероятность ошибиться в их правильном описании… Вот и как исправлять такие ошибки не заходя в секвенсор (особенно, если этот секвенсор требует современную ОСь / .NET)?

[Artem]

в отличие от AIMP:

"Не разбираюсь, но осуждаю"... А кто вам сейчас мешает плагины писать? Пишите парсеры для редактора, в чем проблема?

[«G-Li†ch»]

А разве в редакторе появятся новые поля или в этом же окне возникнет отдельная вкладка или кнопка (наподобие OLE-объекта) для доступа к ним?

Первое, что меня останавливает — "ругащийся" компилятор на отсутствие файлов.lib/.inc — нужно знать кучу -Dключей (и недокументированных тоже?), которые вообще никаким образом не дают понять, как заставить всё собраться… А если брать чужой проект, то тут и makefile не спасает… ох уж сколько ж мне пришлось возиться, чтоб собрать 7-zip — что-то из Win7SDK, что-то пришлось тырить из встроенного в VS2010, возможно ещё и часть от MSKLC, а cvtres.exe и вовсе пришлось заменять файлом из DDKTools (более старой версией), чтоб [LNK1123 COFF INVALID or CORRUPT] не возникал)…
А второе: уже много лет cmake/clang/gcc(miniGNU4Win) "не являются приложеним Win32" на висте, там же и VS2022`ный link.exe требует 7-чные функции kernel32.dll (хотя ml.exe запускается)… и это не говоря про то, что меня эти плюсы (впрочем как и всё поколение B и C языков, вплоть до Rust) в принципе бесят своим синтаксисом, как и многие другие, где используются проклятые "точки с запятой" (они же "знаки вопроса" на элинике)… Можно обойтись и GAS`ом (ezwinports), но не придётся ли мне тогда все заголовочные файлы переписывать (включая отсутствующий windows.h)? Я понимаю, что подавляющее большинство "современных" ассемблерщиков не пишут AT&T-синтаксисом (а мне он нравится больше intel`овских NASM/FASM/MASM/TASM/…), ну, кроме разве что определённого круга "закоренелых" линуксоидов (коим я уж точно никогда не буду)…
В итоге, не только отсутствие всех зависимых стандартных заголовочных файлов/.lib`ов мешает, но ещё и проблемы с самими компиляторами!

[Artem]

А разве в редакторе появятся новые поля или в этом же окне возникнет отдельная вкладка или кнопка (наподобие OLE-объекта) для доступа к ним?

Первое, что меня останавливает — "ругащийся" компилятор на отсутствие файлов.lib/.inc — нужно знать кучу -Dключей (и недокументированных тоже?), которые вообще никаким образом не дают понять, как заставить всё собраться… А если брать чужой проект, то тут и makefile не спасает… ох уж сколько ж мне пришлось возиться, чтоб собрать 7-zip — что-то из Win7SDK, что-то пришлось тырить из встроенного в VS2010, возможно ещё и часть от MSKLC, а cvtres.exe и вовсе пришлось заменять файлом из DDKTools (более старой версией), чтоб [LNK1123 COFF INVALID or CORRUPT] не возникал)…
А второе: уже много лет cmake/clang/gcc(miniGNU4Win) "не являются приложеним Win32" на висте, там же и VS2022`ный link.exe требует 7-чные функции kernel32.dll (хотя ml.exe запускается)… и это не говоря про то, что меня эти плюсы (впрочем как и всё поколение B и C языков, вплоть до Rust) в принципе бесят своим синтаксисом, как и многие другие, где используются проклятые "точки с запятой" (они же "знаки вопроса" на элинике)… Можно обойтись и GAS`ом (ezwinports), но не придётся ли мне тогда все заголовочные файлы переписывать (включая отсутствующий windows.h)? Я понимаю, что подавляющее большинство "современных" ассемблерщиков не пишут AT&T-синтаксисом (а мне он нравится больше intel`овских NASM/FASM/MASM/TASM/…), ну, кроме разве что определённого круга "закоренелых" линуксоидов (коим я уж точно никогда не буду)…
В итоге, не только отсутствие всех зависимых стандартных заголовочных файлов/.lib`ов мешает, но ещё и проблемы с самими компиляторами!

А в этом тоже AIMP виноват?

[«G-Li†ch»]

Ну, что ж, сами напросились: строго говоря, раз в AIMP`е нет никаких средств для создания этих самых подключаемых модулей (или даже банального компилятора/сборщика/компановщика, уже пофиг на «хотя бы текстовый» редактор), то, получается, тоже, да.
А мне всего лишь нужен был ответ на вопрос «как станут доступны "пользовательские" поля в редакторе меток?»…

[Artem]

Ну, что ж, сами напросились: строго говоря, раз в AIMP`е нет никаких средств для создания этих самых подключаемых модулей (или даже банального компилятора/сборщика/компановщика, уже пофиг на «хотя бы текстовый» редактор), то, получается, тоже, да.

AIMP должен иметь свой собственный собственный компилятор? Серьёзно?
Если вы "не умеете" - это не значит, что AIMP не позволяет расширять его функционал за счёт плагинов.

А мне всего лишь нужен был ответ на вопрос «как станут доступны "пользовательские" поля в редакторе меток?»…

Фонотека работает с содержимым базы данных, в базу данных попадает ровно то, с чем плеер умеет работать "из коробки". Выше уже было говорено про это...