ID3 support broken in LAME v3.99.5 ?

I have been using LAME v3.98.2 (from 2008), but just downloaded LAME v3.99.5 (from 2012) from OS4Depot. Seems to work MUCH faster (nearly twice as fast in my test - and ironically much faster than the included old v3.98.2 with G4/Alitvec support)...

... however, I noticed that the ID3 tags (both v1 & v2) are not being written to the created MP3 file. --add-id3v2 does not help.

Anyone else come across this problem, and/or know of a work-around?

I use a separate id3 editor - http://os4depot.net/index.php?functio ... /filetool/id3edit-os4.lha - rather than the id3 features of lame. Both are, in my case, called from the FreeDB_CopyTracks.rexx script integrated with FreeDB, but you can just as well use them separately.

Anyway, since I don't use lame for id3 writing, I haven't noticed this problem, although I do use 3.99.5. It functions well for me otherwise.

Best regards,

Niels

@ChrisH

mpg123 support id3v2 editing.

I'm not sure about audio quality of mpg123, but it might be me who does it wrong.

@ChrisH

Have you tried using Lame with CodeAudio?

That works for me.

Cheers

@ChrisH

I hadn't tried that version, so I downloaded it just now and ran it with the following options

ram:lame-399-5/bin/lame --add-id3v2 --tt "Andy Broad" --tl "Cockerel Blues" Music:AudioEvolution4/Projects/2016_InstrumentalCD/Masters/cockeral_cropped.wav -o ram:cock.mp3

I didn't see any meaningful speed increase (2.53x v 2.45x, both on my SAM-flex ) but I can confirm it does not write that tag information to the file.

Looking in a hex editor, there is an empty ID3 tag at the from (with just encoder info in it) and a blank padded TAG section at the end.

The executable is significantly smaller thanthe old one which make me wonder if it was compliled without ID3 support or something, though then you might expect some error or warning output...

Email the author of the port and ask why he replaced a fully functional tool with a broken one.....

@TiredOfLife

Are you definietly using 3.99.5 with Code Audio or the older version, if you are using the newer version, what optionc isd Code Audio sending to the lame executable?

I did that port 4 years ago. I don't recall having to do anything special with it. Maybe there's some library dependency for id3 tag support that I didn't notice. Doesn't take long to build if someone else wants to give it a go.

Edit: It doesn't look like there's any 3rd party dependencies it's able to use. I wonder if it's an issue with the source or the port.

The file size differences could be just source optimizations in the 4 years difference between those versions (2008-2012), or because the older build in that archive had 3rd party altivec patches applied which may have increased the size. Or maybe it's compiler optimization flags. No idea.

Edit2: typo.

@TiredOfLife
I've not used Code Audio, but given that it sounds like it can READ & write ID3 tags, most likely it does not bother using LAME's ID3tag writing abilities & instead directly reads & writes those tag's itself.

P.S. I am now using ID3tag.library for writing such tags to created MP3s (although Code Audio does not appear to use any library).

@broadblues Quote:
Interesting. I definitely saw an almost 2x speed increase, but I am using an X1000, so maybe there is some clever GCC optimisations used in the newer executable... or it just no-longer uses instructions which make it dead slow on a G4-compatible processor (given how slow the old version was, I favour the latter explanation).

@ChrisH

Now I think about it, the tag info comes from either freedb or CDDB
You get to choose
The tag info is written from that so yeah, CodeAudio is using its own tag editor

@ChrisH
Quote:
I tried v3.99.5 and got no ID3 tags info. I checked an old mp3 that I created with the older lame and a HEX reader shows some tag info near the end of the file. The mp3 I created with v3.99.5 appeared to have some TAG ID's near the top of the file and showed "Blues" as a genre but I entered "Rock" when I created the mp3.

I checked the repository at sf.net and there are more than 20 changes since 2012. Maybe a fresh checkout of the code and a recompile would produce a working version.

I just built the same source under cygwin, and it writes the tag fine. I'll take a look at it again on OS4 "soon".

Edit: Actually, if I remember correctly, I had applied 3rd party altivec patches designed for that version, but people that tested the altivec build had issues, but I still used the same patched source with altivec disabled for the generic build. So perhaps a completely untouched source will be ok, but I'll try with the latest code in the sourceforge repo when I look at it.

Seeing as according to ChrisH, 3.99.5 is much faster than the old G4 build by Stephan Rupprecht, I'll remove that old G4 build in the next upload.

@ChrisH

Unless CodeAudio has chnaged since I last installed it. It's just a wrapper for whatever encoder program you prefer to use.

There again I stopped upgrading because I didn't like the change in GUI layout, so a number of extra features may have been added.

@MickJT

Don't remove that older version just because ChrisH reports positive results on one hardware, it may be that the older version is still faster on the g4 XEs...

When you built the new version did you switch from clib2 to newlib ? (I'm guessing you did due to the shared version). That might make a big difference. (Also accounts for the big change in file size)

If once rebuilt it still doesn't work try using -unix and see if that makes a difference.

@broadblues

I normally use -lunix anyway. If I remember correctly, the G4 build used a lot of tuning flags as well, and the old readme listed what they were. I don't know if it used clib2 or newlib (very easy to see by looking at the binary itself).

When I've got a new version I'll post it here so someone with G4 AmigaOne XE can test it out and compare speeds.

@nbache
Quote:

Wow, great to see that it is still used

Thanks & Ciao,
Alfred

@serpi

Yes, and working well too for me, thanks . Of course I don't really mess with it, I just defined the necessary command line once and for all to make my preferred tags, and thereafter simply let the ripping script call it. But this works without a hiccup.

Do you remember if you had any special challenges porting it? I'm considering whether it would be an idea to try porting the latest ID3v2 from Linux, but I don't have much experience with compiling/building on AmigaOS (yet).

Best regards,

Niels

@nbache

AFAIR id3 was just a recompile (maybe only calling make).

Give it a try

I think the id3v2 needs the id3lib, that's why I didn't port it, but you need to look for yourself.

Ciao, Alfred

@serpi

Yes, that's also my impression (id3lib required).

I'd have to port that first, but I guess that should be possible as well.

We'll see if/when I get some time to look more at it.

Best regards,

Niels

@nbache

You can always come to irc at aw.net

Some people there to give you a hand while porting