Add support for writing ID3v2.3 tags

[GoogleCodeExporter]

Mutagen always supported only saving of ID3v2.4 tags. When I considered using 
it in Picard, I implemented ID3v2.3 support by subclassing the ID3 class. I'd 
like to get this code included in Mutagen, so that we do not have to watch 
Mutagen for changes that could possibly make it incompatible. The code has been 
in use for a couple of years now (and since the majority of Picard uses are on 
Windows, they basically have to use ID3v2.3), so I'm pretty confident it's safe.

Original issue reported on code.google.com by lalinsky on 29 Mar 2011 at 2:43

Attachments:

• id3v23.diff

[GoogleCodeExporter]

I don't have time for a full review right now, but it looks like calling save 
with v2=8 would write an ID3v2.8 tag rather than throwing an exception. While 
one could call this GIGO, I don't like allowing mutagen to write garbage.

Original comment by mur...@gmail.com on 30 Mar 2011 at 2:02

[GoogleCodeExporter]

Sure, the code was used only internally, so I wasn't adding checks like that. 
I'll go through it and add them where necessary.

Original comment by lalinsky on 30 Mar 2011 at 2:05

[GoogleCodeExporter]

To make it easier to review the code, here is the high-level overview of the 
changes:

 - 32bit non-sync-safe frame sizes for v2.3 tags (the only "structural" change)
 - only allow ISO-8859-1 or UTF-16 encoding in textual frames
 - don't allow multiple values in textual frames (join them by "/")
 - convert v2.4 frames TMCL and TIPL to v2.3 frame TIPL simply by taking all values from both frames
 - take the year part from v2.4 TDOR and save as TORY in v2.3
 - convert v2.4 TDRC by splitting it into frames TYER (year), TDAT (month+day), TIME (hour+minute) in v2.3
 - drop unsupported frames

I wasn't sure about enforcing the update_to_v23() call, but if you don't want 
to allow Mutagen to write garbage, then I guess save() should call it 
automatically.

Original comment by lalinsky on 30 Mar 2011 at 2:13

[GoogleCodeExporter]

@lalinsky
thanks! this seems exactly what I was looking for when I posted issue #82

anyone tagging files for Windows users needs to be able to output v2.3

Original comment by e...@anentropic.com on 18 May 2011 at 2:56

[GoogleCodeExporter]

Are there any news to this issue. Are there plans to include the path into the 
trunk and any of the next releases.

There are still new media players which only supports ID3 v2.3 (e.g: Sansa 
Fuze+)

Original comment by schla...@gmail.com on 16 Nov 2011 at 5:17

[GoogleCodeExporter]

I'm considering using Mutagen in a personal project, but lack of support for 
v2.3 tags is indeed a deal breaker for me.  I liked the ability to tag multiple 
audio formats, but to support Windows users and DAPs I need to use 2.3

Original comment by zco...@rhemasound.org on 15 Feb 2012 at 5:40

[GoogleCodeExporter]

*bump* I'm sure the lack of v2.3 writing is not only a huge dealbreaker for me.
EVERYONE who wants to create tags that "just work everywhere" MUST write v2.3 
as there are still tons of applications that do not support v2.4.

Original comment by adr...@planetcoding.net on 2 Jun 2012 at 3:00

[GoogleCodeExporter]

Windows Media Player, Windows Media Center and Windows Explorer in Windows 8 
still don't support v2.4.... Would love to have the option to write tags in v2.3

Original comment by spamisg...@gmail.com on 5 Dec 2012 at 9:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@lalinsky: thx for the patch!

Right now I´m developing a piece of software for windows and would love to see 
native 2.3 support in mutagen.

Original comment by sebastia...@gmail.com on 25 Mar 2013 at 12:48

[GoogleCodeExporter]

Issue 153 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 29 May 2013 at 4:38

[GoogleCodeExporter]

Issue 153 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 29 May 2013 at 5:23

[GoogleCodeExporter]

I wrote a programs using mutagen and realized for some reason Windows Media 
Player and my car music system are unable to read tags. Finally after debugging 
a lot I found that mutagen has written all tags in v2.4 while my Car music 
system, my home theater and Windows Media player 12 on Windows 7 can only read 
v2.3 tags. I would like to vote v2.3 support.

Original comment by tush...@gmail.com on 12 Jul 2013 at 6:29

[GoogleCodeExporter]

Indeed.

Original comment by mats.pet...@gmail.com on 12 Jul 2013 at 10:29

[GoogleCodeExporter]

This issue was closed by revision 5bb62316dd11.

Original comment by reiter.christoph@gmail.com on 5 Sep 2013 at 11:53

• Changed state: Fixed

[GoogleCodeExporter]

Based on the patch above with a slightly different approach:

load(self, filename, known_frames=None, translate=True, v2_version=4)
save(self, filename=None, v1=1, v2_version=4, v23_sep='/')
update_to_v23(self)

load:

 - calls update_to_v23 if v2_version == 3 and translate == True

save:

 - v2 renamed to v2_version so v1 isn't confused with a v1 version
 - instead of merging multivalues and changing encoding in update_to_v23, it gets done behind the scenes on save without changing the frames. I think that's better since it's harder to write off-spec tags this way and update_to_v23 can be called on load without losing multi values. It also allows to write v2.4 style null separators by passing v23_sep=None, which afaik isn't against the spec but might lead to loss of all values except the first (mutagen can still read them).

update_to_v23:

 - I went for removing all v2.4 frames by default. In the case of picard which keeps some of them around it has to load with translate=False, get the frames, update_to_v23, add the frames back. The rest is based on Lukas's patch.

Feedback welcome.

Original comment by reiter.christoph@gmail.com on 5 Sep 2013 at 12:05

[GoogleCodeExporter]

Very nice, Christoph! (I saw your message on IRC belatedly and wanted to 
respond here.) This looks perfect. The way I imagine this working in beets is 
via configuration flag that enables ID3v2.3, in which case update_to_v23 is 
called before every save(). No need to have this on by default.

I was actually content to wait for the rest of the world to catch up to 
ID3v2.4, but this will be even nicer.

Original comment by adrian.sampson on 5 Sep 2013 at 6:02

[GoogleCodeExporter]

Hm, I'm probably looking at this the wrong way, or maybe I already forgot what 
the patch and Picard does, but I can't find the difference in update_to_v23.

I can see it only removing the new ID3v2.4 frames (except that you also have in 
the list those you have migrated in the code above).

What are the frames that we will need to manually add, if I was to port Picard 
to this?

Original comment by lalinsky on 7 Oct 2013 at 8:18

[GoogleCodeExporter]

In case of picard:

 - load(translate=False)
 - get v24 frames you want to write with v23 (TSOP, TSOA, TSOT..)
 - update_to_23()
 - add v24 frames back
 - save(v2_version=3)

Original comment by reiter.christoph@gmail.com on 7 Oct 2013 at 10:01