Generated MP3s are always invalid: mp3val warns about Xing header

[Alan Jenkins]

Invalid files are bad because it impairs your ability to scan for corruption later on.

Using "lame" directly does not cause this problem. MP3s downloaded from Magnatune.com do not have this problem. (You can get free MP3s there if you don't have any valid ones of your own).

This bug is also present in debian tesing (package version 2.0.1-1).

giosrc location="file:///home/alan/01%20Kopenitsa.wav" name=src ! decodebin name=decoder ! audioconvert ! lame quality=2 vbr=4 vbr-max-bitrate=320 vbr-quality=3 ! xingmux ! id3v2mux ! giosink location="file:///home/alan/Unknown%20Artist/Unknown%20Album/01%20Kopenitsa.mp3"
...

$ mp3val 01\ Kopenitsa.mp3
Analyzing file "01 Kopenitsa.mp3"...
WARNING: "/home/alan/mp3/Blowzabella/The Blowzabella Wall of Sound/01 Kopenitsa.mp3": Wrong number of MPEG frames specified in Xing header (11874 instead of 11876)
INFO: "/home/alan/mp3/Blowzabella/The Blowzabella Wall of Sound/01 Kopenitsa.mp3": 11876 MPEG frames (MPEG 1 Layer III), +ID3v2, Xing header
Done!

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: soundconverter 1.5.4-1
ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
Uname: Linux 3.2.0-32-generic x86_64
ApportVersion: 2.0.1-0ubuntu14
Architecture: amd64
Date: Tue Nov 6 10:22:08 2012
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: soundconverter
UpgradeStatus: No upgrade log present (probably fresh install)

[GautierPortet (kassoulet)]

This is a problem in gstreamer xingmux.

[Alan Jenkins (aj504)]

Yeah, if I was more familiar with GStreamer I'd have tried reproducing the chain myself :).

Thanks for looking at this.

[GautierPortet (kassoulet)]

What I found at this point:
- xingmux tries to compute the number of frames from a sum of their duration. And this is wrong, as I've found several rounding errors in the calculation.
- IMHO it's incredibly easier to just count the frames. I've yet to search if using the duration is really needed.

But! With my test vbr-mp3 files, containing 8700 frames, gstreamer is wrong at 8699, but mp3val's 8701 frames are wrong too.
I think mp3val count the frames including empty ones? The file does have an empty first frame, containing the xing header. I'm not sure about what to do with that, I must check how lame generates its xing header.

[GautierPortet (kassoulet)]

Patch sent upstream: https://bugzilla.gnome.org/show_bug.cgi?id=687927

[GautierPortet (kassoulet)]

This is a gstreamer bug, we can only wait.