GNOME Bugzilla – Bug 351171
ID3 tags are not being written properly
Last modified: 2021-05-17 15:56:50 UTC
Please describe the problem: After ripping an album using Sound Juicer I examine the MP3 files using EasyTag and have to manually input all the MP3 tags that Sound Juicer is supposed to have filled automatically. Steps to reproduce: 1. Rip a CD after labelling the tracks, artist, album, etc 2. Examine the MP3s in Easytag 3. Actual results: The tags in Easytag appear empty. Expected results: The tags should be filled automatically by Sound Juicer. SJ should fill all versions of ID3 tags to ensure no matter what software looks for tags it will find it. Does this happen every time? Yes Other information:
What pipeline do you use? Sounds like you have no tag muxer in there.
Interesting point - I had to manually create one in Dapper, and I used this pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc I have no idea how to add a 'tag muxer', as I think I copy-pasted this one from somewhere.
Then try this one: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=2 ! xingmux ! id3v2mux as copy-pasted from https://launchpad.net/distros/ubuntu/+ticket/1005
I'm having a heck of a time tracking down where these options are explained - completely boggled that they're not standard lame parameters cuz that sure looks like some pipes to me. Anyhow, this has had no effect of the ID3 tags of ripped tracks. I've tried searching for xingmux and id3v2mux using apt-cache search to no avail - how do I even find out if I have the necessary things installed?
(In reply to comment #4) > I'm having a heck of a time tracking down where these options are explained - > completely boggled that they're not standard lame parameters cuz that sure > looks like some pipes to me. > > Anyhow, this has had no effect of the ID3 tags of ripped tracks. I've tried > searching for xingmux and id3v2mux using apt-cache search to no avail - how do > I even find out if I have the necessary things installed? > Ah ha! gst-inspect-0.10 lame That shows me my options. I'll continue to troubleshoot.
This is the recommended MP3 profile as documented in the Sound Juicer 2.15 manual: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=0 bitrate=196 ! id3v2mux
I used this pipeline, which really should only change the bitrate I'm ripping to. audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=0 bitrate=128 ! id3v2mux However I still see the same results with the resulting MP3s: Nautilus sees metadata in the Audio properties dialogue. Easytag sees nothing. Here's a response from the Easytag team about what Easytag looks for: "Hi, As EasyTAG uses ID3lib to write tags, it supports ID3v1 tags and ID3v2.3 tags (but not yet ID3v2.4 tags) Regards, Jerome" Is SJ writing ID3v2.4 tags so Easytag can't seem them but Nautilus can?
Yep, id3v2mux writes ID3v2.4 tags
Thanks Christophe! So the issue is that the tags are there but they are not able to be displayed in older software like Easytag. Is it possible to ahve all versions of the tags filled automatically rather than just the v2.4? This would allow any tool that can read any id3 tag to work with the file.
*** Bug 360974 has been marked as a duplicate of this bug. ***
I'm no longer seeing this problem in SJ 2.16.1 on a fresh Edgy install, so it had something to do with my pipeline. However I wonder if it would be possible for SJ to fill all tag versions so that all tools would see the data no matter what version they are reading. Either way, that would be a feature request and this bug can be considered closed from my end. Thanks for the great work folks!
I am seeing this problem on Sound Juicer 2.16.1 in Edgy. Tags written with the id3v2mux can be read by Nautilus and GStreamer apps like Totem, RhythmBox and Listen. Other apps like EasyTag, Audio Tag Tool, the id3 (v0.14) & id3v2 (0.1.11) command line tools can't read the tags. The problem arises when other apps need to access this info. Windows Media Player 9, 10 and 11 can't read the tags, but Winamp can. Can the tags be written at a lower version number?
(In reply to comment #12) > Other apps like EasyTag, Audio Tag Tool, the id3 (v0.14) & id3v2 > (0.1.11) command line tools can't read the tags. > Did you report bugs against those apps as well?
It seems those other linux apps I listed all use id3lib which doesn't support v2.4 tags yet. There is already a bug for it here: http://sourceforge.net/tracker/index.php?func=detail&aid=1500788&group_id=979&atid=100979 However the last release of id3lib was 2003-03-02.
Maybe the authors of those apps could be convinced to switch to a more modern library ;) (taglib comes to mind).
I still think there is some value in having SJ write all versions of tags so that things "Just Work" - is this technically possible? Should I file another bug for this feature request?
I have bought an MP3 player and I realized that it can't read the tags written by sound juicer. After investigation I found out that my MP3 player can only understand ID3v2.3 (and maybe ID3v1, I'm not too sure about it), but gstreamer seems to favour ID3v2.4. In my case using ID3v1 is not an an option the encoding of the songs can't be in unicode. I'm currently writing a gstreamer plugin that can encode an MP3 with ID3v2.3 by using the library id3lib. I think that having such a plugin will give the end users more choice with the tagging of MP3s. Ideally, this plugin could be used to add a an extra tag into the MP3 in order to obtain a bigger compatibility with existing MP3 players by tagging each MP3 simultaneously with IDv1, IDv2.3 and IDv2.4. The plugin, which is named id3v23, is still in its infancy but it's able to add the main tags (with unicode) into an MP3 by using a standalone gstreamer pipeline such as: gst-launch filesrc original.mp3 ! id3demux ! id3v23 ! filesink location=copy.mp3 But for a strange reason I am having some problems integrating the plugin with sound juicer. If I add the plugin to the sound juicer pipeline I can't collect the main gstreamer tags and the plugin can't write any useful information (such as artist, song name, etc). The gstreamer tags that the plugin sees are: discid, discid-full, musicbrainz-discid, musicbrainz-discid-full, track-count, track-number and duration. Is this normal, how is sound juicer adding the other tags? Here's the pipeline that I used with sound juicer: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=0 ! id3v23 Can someone enlighten me?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/56.