GNOME Bugzilla – Bug 637717
Banshee lists incorrect time and bitrate after importing from CD
Last modified: 2011-03-21 15:13:50 UTC
I pop in my CD, and Banshee fetches the metadata and shows me the correct track length (in minutes and seconds). Then I import the CD into my library, and I look at the list in my library and the "Time" for some tracks is all weird. For example, track #1 is 3:52 in real life, but in the library it's showing up as 36:12 at a bitrate of 32 KB/sec. The songs play correctly, so this is just a cosmetic issue, but since I have OCD tendencies when it comes to my music library, this makes Banshee's CD ripping unusable for me. This has happened with both of the CDs that I tried to import, and they both work fine when importing with Rhythmbox. The --debug log is completely clean, except for this (almost definitely) unrelated warning when I mouseover the checkboxes in the CD Audio source: [1 Warn 22:16:12.662] Asked to invalidate 0+0,0x0 for Hyena.Data.Gui.ColumnCellCheckBox but no CanvasManager! Not entirely sure how I can help debug this; let me know.
Ok, before we start jumping to conclusions and blaming Banshee, there is a bit more testing to do. I tested Banshee with the LAME encoder set to 320KB/sec. The Rhymbox import was doing whatever the default OGG settings are, so it might not be a fair comparison. I'll re-test with Banshee using OGG and Rhythmbox using LAME and report back.
Okay, importing as mp3 with Rhythmbox worked fine, as did importing as OGG with Banshee. The problem seems to be LAME-specific in Banshee. When importing with this: audioconvert ! lamemp3enc bitrate=320 target=1 ! id3v2mux Banshee consistently has a hard time figuring out the bitrate and time.
*** Bug 640579 has been marked as a duplicate of this bug. ***
*** Bug 643038 has been marked as a duplicate of this bug. ***
I've played around A LOT with the above lamemp3enc pipeline and it seems that this is actually a gstreamer issue and has nothing to do with Banshee. Encoding like this will give the same cosmetic problems in Totem player as well. I actually tried all combinations of lamemp3enc parameters (excluding mono as this cannot be desired) using gst-launch scripting (bitrate values of 160 and 320). The ONLY way to fix the pipeline is to make it constant bitrate, which will result in audioconvert ! lamemp3enc bitrate=320 target=1 cbr=true ! id3v2mux and give correct time and bitrate readings in both players. I assume that is what Rhythmbox must be doing. I also tried adding queue, audioresample, and mediatype elements in the pipeline before the encoder and nothing at all made a difference, but CBR.
Created attachment 183485 [details] [review] set lamemp3enc audioprofile to CBR when encoding for bitrate attaching a proposed patch to fix mp3 encoder "constant bitrate" option by adding "cbr=true" parameter to lamemp3enc element
Review of attachment 183485 [details] [review]: I haven't looked into the details of the profile parsing recently, but why do you pass "cbr=true" as one argument, instead of "cbr" "true" as a tuple like all the other properties seem to?
I couldn't figure out if that would actually work and therefore relied on the example in wav.xml.in, where an element with complete paramters is passed: (+ "audio/x-raw-int, " "endianness=(int)1234, " "width=(int)16, " "depth=(int)16, " "signed=(boolean)true, " "rate=(int)44100, " "channels=(int)2" ) I admit that I understand even less about profile parsing and I was thinking about above mentioned option as well. It is quite unfortunate that there is no reference to that, as all other profile contain variables as the second parameter. I even read Aaron's old post where he introduced the s-expressions and could figure it out any better. I'll look into the code later today and will come back to this.
Created attachment 183687 [details] [review] set lamemp3enc audioprofile to CBR when encoding for bitrate Gabriel was right, I tested again and the pipeline is now correctly constructed.
Pushed to master
Whoops, re-opening since that patch is only a partial fix.
It's not only a partial fix. I tested the VBR pipeline, it works OK, but only the way it is specified in the profile: "lamemp3enc quality=? target=0". If the target parameter is omitted or changed, then again there is the described behavior.