Just to prove that I am still a tech geek (a badge I wear proudly in the right company), I’ve had to comb through the Intraweb for some specific MP3 encoding parameters I want to try using instead of the stock stuff. I wanted to document the pipeline here so I don’t have to write it down for future reference.
VBR (V=4) encoding pipeline
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-quality=4 ! xingmux ! id3v2mux
CBR (128 Kbps) encoding pipeline
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=0 bitrate=128 ! id3v2mux
Run gst-inspect lame to see the parameters being used here. For example:
mode=1 – sets the lame encoding to use joint stereo
vbr=4 – sets lame to use the “new” VBR encoding algorithm, rather than the old
vbr-quality=4 – sets the encoding bitrate to approximately 165 Kbps, as per the lame settings.
xingmux – pads the MP3 and is only used for VBR settings
id3v2mux – adds the ID3v2 tags to the MP3 (I haven’t figured out a way to add both V1 and V2 tags other than by subsequently using Easytag on the files to add the V1).
nice article. helped clear up a few things.
one problem though.
i currently have my pipeline like this:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=1 ! id3v2mux
however, when i try rip tracks, the bitrate for the mp3s seem much lower than what i would of expected. these pipelines always have me second guessing myself.
You’re not using the xingmux part of the pipe, but you are using VBR encoding. maybe that’s the problem? If not, the other difference is that you’re not using joint stereo (mode=1), try using joint to see if ti affects quality.