Mutagen writes short ID3v1 tag when TDRC is an empty string

[GoogleCodeExporter]

I am using EasyMP3 from Mutagen 1.19 to manage ID3 tags in a couple ways, 
including from a simple GUI. When the date is not filled in, ultimately this 
gets executed:

EasyMP3["date"]=""

This appears to get converted to an empty TDRC tag internally, which is not 
written to the ID3v2.4 tag. That is fine. But I am using the option to also 
write ID3v1 tags, and when this happens, the ID3v1 tag produced is short by 
four bytes (the bytes for the date), and other programs don't recognize that it 
is there. (Windows Media Player shows no tagging info at all on such a file, 
even though the ID3v2.4 tag is up front.) Even Mutagen does not recognize the 
broken tag; subsequent processing by Mutagen causes an additional ID3v1 tag to 
be appended after the short one.

The problem appears to be here in MakeID3v1 in id3.py:

    if "TDRC" in id3:
        v1["year"] = str(id3["TDRC"])[:4]
    elif "TYER" in id3:
        v1["year"] = str(id3["TYER"])[:4]
    else:
        v1["year"] = "\x00\x00\x00\x00"

    return ("TAG%(title)s%(artist)s%(album)s%(year)s%(comment)s"
            "%(track)s%(genre)s") % v1 

There is no check performed to ensure that str(id3["TDRC"]) or str(id3["TYER"]) 
is at least four bytes long, and if it is short you end up with an invalid tag. 
The other portions of the tag appear to be null-padded to the proper length. I 
have attached a diff which fixes the problem.

(This does not fix my files which already have 124-byte ID3v1 tags at the end, 
but I will work on that myself...)

Original issue reported on code.google.com by dev...@gmail.com on 22 Aug 2010 at 2:01

Attachments:

• id3.py.diff

[GoogleCodeExporter]

Technically a "" TDRC value is not a valid ID3v2 tag either. But yeah, since it 
breaks ID3v1 much worse it should get fixed (and probably get something to 
detect this by looking for TAG anywhere between 128 and 124 bytes from the end 
of the file).

Original comment by joe.wreschnig@gmail.com on 22 Aug 2010 at 9:00

• Changed state: Accepted

[GoogleCodeExporter]

As a comment on the proposed fix, I think that it'd be easier to read the 
following instead of the math. (I was hoping something like zfill would work, 
but it looks like it only uses "0")

v1["year"] = ("\x00\x00\x00\x00" + v1["year"])[-4:]

Original comment by mur...@gmail.com on 25 Aug 2010 at 12:57

[GoogleCodeExporter]

Original comment by joe.wreschnig@gmail.com on 18 Sep 2010 at 8:46

• Added labels: NeedsTest

[GoogleCodeExporter]

This issue was closed by revision r94.

Original comment by joe.wreschnig@gmail.com on 27 Oct 2010 at 12:41

• Changed state: Fixed