lower-case vorbis comments breaking iaudio hardware player

[GoogleCodeExporter]

I've been experimenting with METADATA_BLOCK_PICTURE in vorbis audio files, ala 
the spec here:

http://wiki.xiph.org/VorbisComment#Cover_art

My impetus was that I have a bunch of .ogg files tagged via Picard that have 
"coverart" tags in them, which seem to make the previously playable files 
UNplayable on my iAudio U3 hardware player (chosen principally for its ogg 
support...).

The page referenced above notes that picture-embedded files have been tested 
and do work on this player, and indeed, the provided sample file(s) do work. 
So, I set about making one of my non-working files work. I figured it out (I'll 
provide a script here for smarter folks than I to either integrate, or just for 
posterity).

Except, I noticed that mutagen seems to lower-case the tag names when .save() 
is called on the file... so METADATA_BLOCK_PICTURE becomes 
metadata_block_picture, which seems to freak out my player. I expect that this 
is a bug in the player, but it seems on the Xiph page that they describe tags 
in ALL UPPERCASE, so I'm wondering why mutagen forces them to lower even if 
they were set as upper.

Original issue reported on code.google.com by matt.fei...@gmail.com on 16 Sep 2011 at 11:08

[GoogleCodeExporter]

Oops; didn't mean to mark it "enhancement"... I think it might be a bug: if I 
send-in upper-case tag names, don't "fix" it for me.

Original comment by matt.fei...@gmail.com on 16 Sep 2011 at 11:08

[GoogleCodeExporter]

The Vorbis spec states that the fields are case-insensitive so we need to 
normalize the field names somehow. And uppercase is horrible to read, so we use 
lowercase.

If this was any field but metadata_block_picture I'd care a lot more. It's 
ridiculous to push for such a bogus field and then be so incompetent you can't 
get case-sensitivity right.

I'd consider a patch to allow a custom field name normalization function to be 
passed to the relevant constructors, with the default being the current 
behavior.

Original comment by joe.wreschnig@gmail.com on 17 Sep 2011 at 1:24

[GoogleCodeExporter]

I hear you Joe... but it turns out that after digging further, it's not the 
problem I thought... there were two differences between the reference one that 
worked and the one I created with mutagen that didn't work:

1. case of tag name.

2. the bs encoded picture payload to the tag name... the reference (a flac 
picture) seems to actually be a LIST of one flac picture element... the one I 
made was just one.

After noticing this, if I force the tag to be [chunk_of_encoded_data] rather 
than just chunk_of_encoded_data, it works.

So, you can ignore/delete this request.

Original comment by matt.fei...@gmail.com on 5 Oct 2011 at 2:54

[GoogleCodeExporter]

Original comment by joe.wreschnig@gmail.com on 11 Dec 2011 at 10:23

• Changed state: Invalid