[SOLVED] ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Help improve MediaMonkey 5 by testing the latest pre-release builds, and reporting bugs and feature requests.

Moderator: Gurus

PeterXXX
Posts: 33
Joined: Sat Oct 08, 2016 3:33 pm

[SOLVED] ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by PeterXXX »

All my older MP3 files have ID3v2.3 tags as they where created with MM4.
Working on those tags in MM5 where I chose ID3v2.4 could result in 'Bad ID3v2' leaving only ID3v1 tags readable and the loss of all other tags.
This behaviour may depend on the tags changed. It surely happened when only adding an image (i.e.).
Music library of about 36.000 items (MP3, FLAC),
mainly maintained with MM5 (lifetime license) and Mp3tag,
on Win10 x64 22H2,
stored on Synology NAS DS218+ running MinimServer.
Lowlander
Posts: 56630
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by Lowlander »

Please add more detail as to what you mean with bad ID3v2 and which build of MediaMonkey 5 you're using.
PeterXXX
Posts: 33
Joined: Sat Oct 08, 2016 3:33 pm

Re: ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by PeterXXX »

Lowlander wrote: Mon Nov 23, 2020 6:25 pm Please add more detail as to what you mean with bad ID3v2 and which build of MediaMonkey 5 you're using.
Using actual build 2275.
In MM5 the tags seem to be ok incl. image stored in tags, though the custom (sort) tags are lost.
(btw they are not shown if present in other MP3 files!)
Mp3tag shows under 'Tag': 'ID3v1 (ID3v1 !BAD ID3v2)' instead of 'ID3v2.4 (ID3v1 ID3v2.4)' and image, album artist, disc# and other tags are missing.
MinimServer log lists:
Warning: ID3v2.4 'õÀU½' frame size has incorrect format at offset 22380 in file Rod Stewart/The Great American Songbook, Vol. V (Deluxe Edition)/1-01 That Old Black Magic.mp3 (length 8091648)
Warning: unable to complete reading ID3v2 tag data at offset 22384 in file Rod Stewart/The Great American Songbook, Vol. V (Deluxe Edition)/1-01 That Old Black Magic.mp3 (length 8091648)
Selection of 'Edit tags' --> 'Update tags' in MM5 didn't change anything.
Music library of about 36.000 items (MP3, FLAC),
mainly maintained with MM5 (lifetime license) and Mp3tag,
on Win10 x64 22H2,
stored on Synology NAS DS218+ running MinimServer.
PeterXXX
Posts: 33
Joined: Sat Oct 08, 2016 3:33 pm

Re: ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by PeterXXX »

PS: Inspecting the file with 'HxD Hex Editor' showed all the missing tags!?
Do you eventually use some special tagging for images added with 'Lookup image' option?
MiPi
Posts: 871
Joined: Tue Aug 18, 2009 2:56 pm
Location: Czech Republic
Contact:

Re: ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by MiPi »

PeterXXX: could you send me some affected files (use PM and some file sharing service), which are with correct ID3v2.3 and then the same files with those bad ID3v2.4? Ideal would be original file + exact steps of tagging in MM5 + resulting file, I will analyze, where could be the problem, thanks.
We use standard tagging, nothing special after Lookup image.
PeterXXX
Posts: 33
Joined: Sat Oct 08, 2016 3:33 pm

Re: ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by PeterXXX »

By now I'm quite sure about what went wrong.
As I'm using MM4 (for ripping to FLAC with Discogs addon) and MM5 (for format conversion to MP3, ID3v2.4) to maintain identical libraries (one for each format), I strive to avoid changing MP3 files in MM4, which correctly reads ID3v2.4 tags but supports writing of ID3v2.3 tags only.
For the questionable album, already tagged with ID3v2.4, I added/changed 'Grouping' and 'Original Title' in MM4 before realizing that I used the 'wrong' program. After looking at this album in MM5 the image was gone and re-added with 'Lookup Image'.
But the mischief was already done. It seems that MM4 does not correctly reformat tags back to ID3v2.3, that is why I rarely experienced the same errors in 'Mp3tag' and 'MinimServer' before.
So it's not a MM5 issue! Just my fault and I beg your pardon.
Btw the offsets in MinimServer log point to the last 140 resp. 136 bytes of the APIC block (in the above case).
Music library of about 36.000 items (MP3, FLAC),
mainly maintained with MM5 (lifetime license) and Mp3tag,
on Win10 x64 22H2,
stored on Synology NAS DS218+ running MinimServer.
MiPi
Posts: 871
Joined: Tue Aug 18, 2009 2:56 pm
Location: Czech Republic
Contact:

Re: [SPLVED] ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by MiPi »

Even this does not make sense and should not occur (it would destroy tags in files for many MM4 users and this is not happening). MM4 should not destroy ID3v2.4 tag by tagging, it simply tags the file with ID3v2.3, but all values should be preserved. I have tested it and for me and my files it works without problems. Could you PM me sample of your files which will manifest this? I.e. file after rip - this file after tagging by ID3v2.4 - this file after tagging by MM4 with image gone.
Do you use last version of MM4 (4.1.30.1914)?
PeterXXX
Posts: 33
Joined: Sat Oct 08, 2016 3:33 pm

Re: [SPLVED] ID3v2.3 to ID3v2,4 tagging results in 'Bad ID3v2'

Post by PeterXXX »

MiPi wrote: Wed Nov 25, 2020 3:05 am Even this does not make sense and should not occur (it would destroy tags in files for many MM4 users and this is not happening). MM4 should not destroy ID3v2.4 tag by tagging, it simply tags the file with ID3v2.3, but all values should be preserved. I have tested it and for me and my files it works without problems. Could you PM me sample of your files which will manifest this? I.e. file after rip - this file after tagging by ID3v2.4 - this file after tagging by MM4 with image gone.
Do you use last version of MM4 (4.1.30.1914)?
Sorry that it took so long for a reply.
Unfortunately I could not reproduce the described behaviour, neither in MM5 nor in MM4. Many of the older files in my MP3 library still have ID3v2.3 tags and were created with different apps from my pre-MM time, mainly with iTunes and reworked with i.e. foobar2000 and/or mp3tag. With the latter the tagging was fixed again to ID3v2.4.
Post Reply