I'm not an IRC person, though, and apart from that, my first problem will probably be to find time to start this project. It won't happen any time soon.
I've tracked this down to the usage of iconv when ID3TAGS_EXTENDED is defined. If I disable ID3TAGS_EXTENDED, then it's all good, but limits tags to ASCII (i.e raw). If that isn't ok, then I think someone else might need to take a look at it (it's in frontend/parse.c).
I've tracked this down to the usage of iconv when ID3TAGS_EXTENDED is defined. If I disable ID3TAGS_EXTENDED, then it's all good, but limits tags to ASCII (i.e raw). If that isn't ok, then I think someone else might need to take a look at it (it's in frontend/parse.c).
I looked at the lame-3.98.5 parse.c code and found this:
TENC_UTF16 /* text will be converted from local encoding to Unicode, as ID3v2 wants it */
which implies that ID3v2 TAGS might not work if you disable ID3TAGS_EXTENDED. I suggest you try to encode an MP3 with a title that has more than 30 chars to see if it works.
I checked the lame-3.98.4 parse.c code and found this:
TENC_UCS2 /* text will be converted from local encoding to UCS-2, as ID3v2 wants it */
Since the lame-3.98.4 ID3v2 is using UCS-2 encoding and is working and the lame-3.98.5 ID3v2 is using Unicode (UTF_16) and doesn't work, it's possible that the iconv code in newlib's libc needs to be updated.
I tested the encoding speed of lame-3.98.4 with the encoding speed of lame-3.98.5 (from OS4Depot) using the "timer" command from OS4Depot and lame-3.98.4 was twice as fast as lame-3.98.5 with a 1 minute CDDA file source encoded with 320kbps and max quality.
Unless you can get lame-3.98.5 working with ID3v2 tags, I suggest you replace it at OS4Depot with lame-3.98.4 from 2010 until someone can figure out how to fix 3.98.5. (libmp3lame too??)
The above is mostly speculation on my part, since I can't compile lame.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I can't run the 3.98.2 build on my machine, but I opened it up in a text editor and couldn't see any reference to newlib.library, so I think it was built with clib2. That usually means iconv wouldn't have been enabled. Soon I'll try a build with iconv disabled and see what happens.
In liveforitmusic I display the ID3v2 using UTF8 my library, and looks correct to me. are you sure UCS-2 is correct?
UTF16 is almost never used, as it's incompatible with US ASCII 7bit, and it also the issue of leading 0's, normally considered 0 terminated strings in ASCII.
All this issues are avoided with UTF8, (but I'm sure UTF8 is bit heavier to decode.)
UCS-2 sort of looks like UTF16 but without the encoding (a UCS-2 char is 2 bytes no more). The strength of UTF8/UTF16 is that one char is not a fixed amount of bytes, saves space, but extended to the 32bit range.
Edited by LiveForIt on 2016/9/13 22:16:35 Edited by LiveForIt on 2016/9/13 22:17:47 Edited by LiveForIt on 2016/9/13 22:18:17
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@MickJT It looks like the 3.98.4 code has altivec support which might explain why it's faster that 3.99.5 on my X1000. By the way it looks like the lame sources at sf.net are up to version 3.100.2 and I see commits in 2016.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
You might need to set the executable bit after downloading. It's 3.99.5 with HAVE_ICONV undefined. id3v2 tags seem to be working, although it wouldn't be doing any Unicode/UCS conversion (I doubt 3.98.2 was either).
Edited by MickJT on 2016/9/14 4:53:44 Edited by MickJT on 2016/9/14 6:56:44 Edited by MickJT on 2016/9/14 7:02:01 Edited by MickJT on 2016/9/14 14:34:30
The ID3-V2 (forced by a long comment field) and IDV3-v1 feilds all seem to be written. With a literal copy of what I typed on the command line, no encoding.
Comparing with the tags created by 3.98.2 they seem identical.
File size is ony 3 bytes a part overall. The diference being explained by the 3 extra bytes in the website name embedded in the ID3 tag.
Just noticed you and I were getting the version numbers mixed up. I assume when you said 3.98.5 you meant 3.99.5. Also the G4/altivec build on OS4Depot (in the same archive) is 3.98.2, not .4. Anyway, that's not of much importance :) I fixed up my posts.
@broadblues
I'm a little confused. Identical but 3 bytes longer?
Do you mean the format is the same but you typed in a tag (a website name) that was 3 bytes longer?
Which file are you getting that version number from?
I got the version number from libmp3lame/version.h and because the last number in the version when I did "lame -v" (with 3.98.4) matched the LAME_PATCH_VERSION definition in the version.h file, I assumed that definition was where the " .4 " came from. I could be wrong.
Quote:
Just noticed you and I were getting the version numbers mixed up. I assume when you said 3.98.5 you meant 3.99.5. Also the G4/altivec build on OS4Depot (in the same archive) is 3.98.2, not .4. Anyway, that's not of much importance :) I fixed up my posts.
When I downloaded the 3.99.5 version from OS4Depot I backed up the lame archive that I downloaded from OS4Depot in 2010. The 2010 archive on my hard disk lame.lha has the OS4Depot URL in the comment so I'm sure I got it at OS4Depot. My 2010 archive has these files in the bin directory:
@MickJT I tested your new lame 3.99.5 and the tags seem to work now. I also used the timer command (OS4Depot) to compare the conversion times for a 1 minute CDDA file using the same lame options and got this:
lame 3.99.5 took 33.1967 seconds. lame 3.98.4 took 18.5711 seconds.
The resulting MP3 files were exactly the same size.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I could do that and see if it works, but that would mean bundling the .so with the binary. The libmp3lame library itself I don't think is affected, since all this iconv code is only part of the frontend utility.
But, if people are happy just having iconv disabled and the results from that, then I'd rather just do that so it's just the one file. Perhaps ffmpeg is able to write UTF-16 tags.
@xenic
My comment where I asked where you got the version number from was about 3.100.2. I see where the "2" is in that header file now on the CVS repo.
There was at least one port of mine after Stephen's 3.98.2, and before 3.99.5. And I know at one point I had released an altivec build but replaced it with Stephen's older version after reports of mine not working properly. Perhaps it did for some and not for others.
As for speed, I'll try to find that 3rd party altivec patch again for 3.99.5 and give it one more go... soonish. (Edit: I see there's a source for the MOS port on Aminet with the altivec patch applied).
'm a little confused. Identical but 3 bytes longer?
Do you mean the format is the same but you typed in a tag (a website name) that was 3 bytes longer?
The files are the same except the three bytes different due to the length of the lame.sf.net verses www.mp3dev.com urls that lme places in the in the ID3v2 TSSE section.
I could do that and see if it works, but that would mean bundling the .so with the binary. The libmp3lame library itself I don't think is affected, since all this iconv code is only part of the frontend utility.
There is also a static library in the archive I linked to and if that one is too old one could always try building a newer libiconv.
Not sure that I want to add a dependency that it didn't have before. I could take a look at compiling iconv and statically linking it (or using the one in that archive). Is it easy to override the one that comes with newlib?
How important is it, though? Perhaps in the future, but as it is we can't even write non-ASCII characters in the shell, right?
"How important is it, though? Perhaps in the future, but as it is we can't even write non-ASCII characters in the shell, right?"
It's true the console is ASCII, but it's not a big problem.
it's just a matter of converting ASCII, like this Glyph = CodePage[ ASCII ], this glyph codes can then be stored as UTF8 and be preserved correctly, so when you have mp3 player that can display UTF8 text it does display all glyphs correct for all languages, provided you have Font that does have the glyphs you wont to display that is.
This mostly a problem for none US/UK/Australian people, but if can read and talk multiple languages, you might want to keep it in original language Japanese and chinse or Russian, Arabic in its original languages.
As I pointed out before US ASCII 7bits is compatible with UTF8, all other languages however is not 1 to 1 the same as the chars are encoded.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
So, the way it is at the moment, is there an issue if someone in Europe for example types an accented character on OS4 and then tries reading that tag on a PC?
There was at least one port of mine after Stephen's 3.98.2, and before 3.99.5. And I know at one point I had released an altivec build but replaced it with Stephen's older version after reports of mine not working properly. Perhaps it did for some and not for others.
As for speed, I'll try to find that 3rd party altivec patch again for 3.99.5 and give it one more go... soonish. (Edit: I see there's a source for the MOS port on Aminet with the altivec patch applied).
The lame 3.98.4 archive contains the sourcecode and there is a file named "lame-3.98.4-altivec-20100323.diff" in the main directory of those sources. The MOS patch looks a lot different than the the one in the OS4 lame 3.98.4 sources. If the MOS patch doesn't work then the lame-3.98.4 patch would probably need to be adjusted to account for changes in the patched files for the lame-3.99.5 sourcecode.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
