Вообще по стандарту, в тегах мп3 ДОЛЖНА быть кодировка утф-8. А сия проблема произрастает именно из некрофилейного софта, который был не «винапиабле» ничего кроме цп-1251. Вот так они и писали туда шопопало.
Так что можно еще передать пламенный привет авторам того софта, и писателям тех тегов на том софте. Шоп у них у всех уши горели.
Согласен. Но в интернете вот так. Скачал Чижа «Гайдном буду», а тут такая фигня в 1251. Я могу и на десктопе конвертнуть, но хотелось сразу на телефоне...
Вообще по стандарту, в тегах мп3 ДОЛЖНА быть кодировка утф-8.
никому она не должна. id3v2 по стандарту поддерживает ucs-2 (le/be), utf16 (le/be), iso8859-1, utf8, причем разные версии id3v2 поддерживают разные кодировки. например, самый распространенный id3v2.3 вообще не поддерживает utf8.
If nothing else is said a string is represented as ISO-8859-1 characters in the range $20 - $FF. Such strings are represented as <text string>, or <full text string> if newlines are allowed, in the frame descriptions. All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.
пруф два (id3v2.4 — уже не позволяет ucs-2, зато позволяет utf16 и utf8)
Frames that allow different types of text encoding contains a text
encoding description byte. Possible encodings:
$00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
$01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
strings in the same frame SHALL have the same byteorder.
Terminated with $00 00.
$02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
Terminated with $00 00.
$03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
а id3v1 вообще не умеет никакой юникод. не помню точно, что там было задумано изначально — ascii, или iso8859-1. короче, русский текст там не мог быть вообще в принципе, но писали все кто ни попадя «в чем было».
btw, если не воротит от очень простого интерфейса, и отсутствия медиа-библиотеки — то deadbeef на андроиде умеет автодетектить кодировку, и ничего не надо конвертировать.
Тем не менее, как объяснить факт того, что все плеера пытаются читать теги как утф-8, а не все остальное?
они этого не пытаются. напротив, они читают по стандарту. т.е. как iso8859-1. но т.к. записано в файле cp1251 - получается билиберда. есть несколько плееров которые умеют автодетект кодировки. чуть большее количество плееров позволяет указать кодировку вручную. но этот способ плохой, т.к. если в файле _действительно_ iso8859-1 — то перекодирование в cp1251 выдаст билиберду.
Не в тему топика, да не обидится на меня ТС, и да не отпинают меня модеры:
Вот тут (и в аналогичных ей) https://github.com/Alexey-Yakovenko/deadbeef/blob/master/replaygain.c#L154 ты же просто отрезаешь верхушки пиков относительно некоторой «нормали» и если текущее значение фрейма ниже(pos)/выше(neg) этой «нормали» то ты его не трогаешь. Т.е. работает оно как лимитер с нулевой задержкой.
А я вот все хочу наколдовать чонить с чтением, анализом небольшого буфера и мягким «прибиванием» по амплитуде с учетом предыдущего состояния лимитера (куда он шел, жал или отпускал), пусть даже линейно, но на максимальных амплитудах «прибивать» уже жостко. Как считаешь оно того стоит?
??? ведь старое значение близкое к пиковому, после умножения будет уже слишком большим при максимальном значении get_int_volume() (кстати какое оно там максимальное?) и мы попадем в условия ниже, на выходе может случиться примерно такое http://i1.creativecow.net/u/131460/waveform.png или я что-то проглядел?