GNOME Bugzilla – Bug 629039
id3v2mux and id3mux do not pass "compilation" and "albumartist" tags through
Last modified: 2012-10-06 12:00:19 UTC
Created attachment 169744 [details] test script and (copyright free) test audio files While using gstreamer with id3v2mux to convert flac files to mp3, I noticed that some tags presents in the flac where not present in the mp3. Namely, the "compilation=1" and "albumartist=Various Artists" in the tags should have been converted into "TCMP=1" and "TPE2=Various Artists" in the mp3 file, but are not. This is patent when you use iTunes, because it screws up cover flow. Additional tests showed that 1) id3v2mux successfully passed the tags if both input and output files where mp3 2) id3mux failed with both input files. In short the test matrix is: flac --id3v2mux--> mp3 KO flac --id3mux----> mp3 KO mp3 --id3v2mux--> mp3 OK mp3 --id3mux----> mp3 KO I use id3v2mux 0.10.21 and id3mux 0.10.18 on an ubuntu lucid computer. I'll attach the conversion script and the audio files. I created the audio files for the occasion and tagged them with picard.
We currently don't have a gstreamer tag that means 'compilation', sometime ago there was a discussion about a similar tag (or was it compilation itself?) and some people were against adding 'boolean' type tags. I see no problem in it, should we have a GST_TAG_PART_OF_COMPILATION?
Meanwhile the album artist is fixed on the following commits: in -bad commit 768babf968abf0f67f964a07d1d26e2a89d012fb Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Wed Sep 8 16:57:57 2010 -0300 id3mux: Map GST_TAG_ALBUM_ARTIST Map GST_TAG_ALBUM_ARTIST to TPE2 as it is done in -base id3tag mappings. in -good commit 418bca8c0f96b224ded456f7eabdc63e589fa902 Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Wed Sep 8 17:07:53 2010 -0300 id3v2mux: Adds mapping for album artist Maps GST_TAG_ALBUM_ARTIST to TPE2 in id3v2mux
The question however is still why it didn't preserve those tags. Does id3demux deserialise them correctly into 'private' frame blobs? Does id3v2mux pick those up? Does taglib then not parse them correctly when we feed them to it? (maybe they're not id3v2.4 and then it fails to convert them or something?)
id3demux seems to properly put the tags into private blobs, but the TCMP field is not official. id3mux spills some: "WARN id3mux id3tag.c:520:add_id3v2frame_tag: Discarding unrecognised ID3 tag for different ID3 version" id3v2mux is working properly now. PS.: This is only for the .mp3 input, still haven't tested the flac input
Looking at the flac tags it seems everything is extracted into 'extended-comment' items and then it is serialized back as such into id3.
(In reply to comment #5) > Looking at the flac tags it seems everything is extracted into > 'extended-comment' items and then it is serialized back as such into id3. By 'everything' I mean the unknown/non-identified tags, including the compilation one.
Any ideas on what we could do here? How about having a property to allow those non-official but widely used tags for id3?
Confirmed it works now. "compilation" is passed to 1 or Yes. 1 for all except output_mp3_id3v2mux.mp3 that has 'Yes'. The 'Artist: Various Artists' is kept in all as well. Setting as Resolved