encoding to mp3vbr is missing lame headers

[https://www.google.com/accounts/o8/id?id=aitoawntq-j7jbthy0dbtyuacb9d9av0d59mumc]

I've been struggling for a while trying to get gapless playable mp3s from morituri, but always end up with files with a tiny hiccup of silence at the end. After a stack of research I think I've tracked down the problem to missing lame headers in the mp3 files produced by morituri.

I've compared the files output by morituri to similar files produced by EAC...

From morituri:

$ eyeD3 --lametag 01.\ Café\ Tacvba\ -\ Seguir\ siendo.mp3

1. Café Tacvba - Seguir siendo.mp3 [ 4.02 MB ]

---

No LAME Tag

From EAC:

$eyeD3 --lametag Track01.mp3

Track01.mp3 [ 3.77 MB ]

---

Encoder Version : LAME3.98r
LAME Tag Revision : 0
VBR Method : Variable Bitrate method2 (mtrh)
Lowpass Filter : 18500
Radio Replay Gain : -2.0 dB (Set automatically)
Encoding Flags : --nspsytune --nssafejoint
ATH Type : 4
Bitrate (Minimum) : 192
Encoder Delay : 576 samples
Encoder Padding : 960 samples
Noise Shaping : 1
Stereo Mode : Joint
Unwise Settings : False
Sample Frequency : 44.1 kHz
MP3 Gain : 0 (+0.0 dB)
Preset : V2
Surround Info : None
Music Length : 3.77 MB
Music CRC-16 : 07F9
LAME Tag CRC-16 : E5BF

It's the encoder delay and encoder padding tags which are the important ones. I think somewhere in the gstreamer element which is encoding the mp3 through lame these tags are getting stripped.

Morituri does a fantastic job of ripping the cds, it's just the encoding which is a problem. Thanks for the time you've put into this tool - it's really appreciated!

[http://www.google.com/profiles/pharmst]

Have you tried changing the gastreamer string in common/encode.py to add the xingmux filter?

Something like 'lamemp3enc name=tagger quality=0 ! xingmux ! id3v2mux' may do the trick.

[http://www.google.com/profiles/pharmst]

Having tried it, that doesn't work.

[https://www.google.com/accounts/o8/id?id=aitoawntq-j7jbthy0dbtyuacb9d9av0d59mumc]

Yup, I've already tried with the xingmux filter but to no effect. That said, perhaps the xingmux filter should be added into the pipeline in any case, since it will help make the resultant files more compatible with quirky players?

Digging a bit deeper, I'm starting the think this could be a gstreamer bug, since none of the gstreamer-based rippers/converters I've tried leave the lame headers intact. Does this sound likely? If so, I'll chase it up with the gstreamer folks.

[http://www.google.com/profiles/pharmst]

Yes, morituri should probably apply the xingmux plugin in before the id3 tag plugin.

This is a gstreamer issue: the problem is that you have to keep hold of the entire stream & call lame_get_lametag_frame() right at the end to get an extra frame with the tags in which you then have to use to overwrite a blank frame that lame put in right at the beginning of the stream.

There really ought to be an option to do this in gstreamer, but no-one has written the code...

[https://www.google.com/accounts/o8/id?id=aitoawntq-j7jbthy0dbtyuacb9d9av0d59mumc]

Ok, I've reported it here:

 https://bugzilla.gnome.org/show_bug.cgi?id=620322