Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug handling ID3 v1.0 vs v1.1 comment field causing overflow into track field #668

Open
PsynApps opened this issue Jan 2, 2025 · 0 comments

Comments

@PsynApps
Copy link

PsynApps commented Jan 2, 2025

Mutagen appears to not check whether a file has ID3 v1.0 or 1.1 tags when reading the comment field. This is a problem because in IDv1.0, the comment field can be up to 30 bytes in length, but in 1.1, the comment field can only be 28 bytes, with byte 29 required to be 0, and byte 30 used to represent the track number.

It seems as though Mutagen treats all ID3v1 tags as following the v1.1 specification. Thus, when a file has an ID3 v1.0 tag with a comment that is 30 bytes long, the 30th byte of the comment will be cast to an integer and used as the TRCK ID3 field.

I am using Mp3tag to demonstrate this issue. Mp3tag is clever and decides whether to write a v1.0 or v1.1 ID3v1 tag based upon whether a track number is defined or not. If no track number is defined, Mp3tag will save the tag as v1.0 with 30 bytes for the comment field to store as much of the full comment as possible. However, if a track number is defined, Mp3tag will instead save it as a v1.1 tag with only 28 bytes in the comment field.

The comment I am trying to write in the comment field is "This comment exceeds the length allowed by ID3v1".

If I save this file without a track number, Mp3Tag writes an ID3v1.0 tag as follows:

C:\temp>eyed3 -1 "test.mp3"
-------------------------
...C:\tmp\dialupmodem.mp3[ 113.10 KB ]
-------------------------
Time: 00:26     MPEG2, Layer III        [ ~35 kb/s @ 8000 Hz - Mono ]
ID3 v1.0:
title: Dial-up Modem
artist:
album:
track:
Comment: [Description: ID3v1.x Comment] [Lang: eng]
This comment exceeds the lengt
-------------------------

When this file is loaded by Mutagen, it reports the following tag fields, which demonstrates the bug:

{
  'COMM::XXX': COMM(encoding=<Encoding.UTF8: 3>, lang='XXX', desc='', text=['This comment exceeds the length allowed by ID3v1']),
  'TIT2': TIT2(encoding=<Encoding.UTF8: 3>, text=['Dial-up Modem']),
  'COMM:ID3v1 Comment:eng': COMM(encoding=<Encoding.LATIN1: 0>, lang='eng', desc='ID3v1 Comment', text=['This comment exceeds the leng']),
  'TRCK': TRCK(encoding=<Encoding.LATIN1: 0>, text=['116'])
}

TRCK is inappropriately defined and assigned the value 116, which corresponds to the ASCII code for 't' (the 30th character of the ID3v1 comment).

However, if I save this file with the track number 1, Mp3Tag instead writes an ID3v1.1 tag as follows:

C:\tmp>eyed3 -1 dialupmodem.mp3
...C:\tmp\dialupmodem.mp3[ 113.10 KB ]
-------------------------
Time: 00:26     MPEG2, Layer III        [ ~35 kb/s @ 8000 Hz - Mono ]
-------------------------
ID3 v1.1:
title: Dial-up Modem
artist:
album:
track: 1
Comment: [Description: ID3v1.x Comment] [Lang: eng]
This comment exceeds the len
-------------------------

This file is handled correctly by Mutagen with the following fields:

{
  'COMM::XXX': COMM(encoding=<Encoding.UTF8: 3>, lang='XXX', desc='', text=['This comment exceeds the length allowed by ID3v1']),
  'TIT2': TIT2(encoding=<Encoding.UTF8: 3>, text=['Dial-up Modem']),
  'TRCK': TRCK(encoding=<Encoding.LATIN1: 0>, text=['1']),
  'COMM:ID3v1 Comment:eng': COMM(encoding=<Encoding.LATIN1: 0>, lang='eng', desc='ID3v1 Comment', text=['This comment exceeds the len'])
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant