[FFmpeg-devel] [PATCH 1/3] Add replay_gain and find_peak_sample options to libmp3lame

Giovanni Motta giovannimotta at google.com
Sat May 24 21:48:33 CEST 2014


> What you were looking for here was probably the --compose option

Thanks, it makes sense. First time using git.

> there should be an error or warning printed if the user specifies an
option that doesnt work with the used Lame

I will look at a clean way to do this. The setting is implemented in Lame
as "replay gain accurate" and it silently reverts to "replay gain fast" if
the decoder is not linked (to compute the peak signal, Lame decodes each
mp3 frame after the encoding).

> missing documentation (in doc/...)

Will add the missing doc and give it another try on Tue.

Thanks

Giovanni



On Sat, May 24, 2014 at 6:28 AM, Clément Bœsch <u at pkh.me> wrote:

> On Fri, May 23, 2014 at 07:40:14PM -0700, Giovanni Motta wrote:
> > Add Lame tag to the Xing/Info header of mp3 files.
> >
> > Fixes ticket #3577
> >
> > A few notes/comments:
> >
> > - A failing FATE test has been updated with new CRC.
> >
> > - The Lame info tag is generated by libmp3lame and passed to the mp3enc
> via extradata.
> >
> > - To keep the size of the tag constant and simplify the code, vbr_scale
> is always added.
> >
> > - The Lame string vendor in the tag is fixed length, so vendor is trimmed
> >   to 9 bytes and padded with 0x20 if shorter.
> >
> > - replay_gain and find_peak need a version of lame patched with
> >   libmp3lame/lame.c Revision 1.367 (patch tracker item #66):
> http://sourceforge.net/p/lame/patches/66/
> >   They have no effect otherwise.
> >
> > - find_peak_sample only works if Lame is configured with
> --enable-decoder.
> >   It has no effect otherwise.
> >
> > - Some fields in the Lame tag are not set because not accessible from
> >   the set/get API (preset and noise shaping, for example). I will bring
> this to
> >   the attention of the Lame developers and help there with any change if
> we
> >   decide to merge the patch.
> >
> > Thanks
> >
> > Giovanni
> >
>
> Note: you copied this in the description of each patch. If applied as
> such, this description will end up in every commit, which is probably not
> what you/we want. What you were looking for here was probably the
> --compose option of git-send-email (which create a PATCH 0/N mail with
> that description) and not --annotate (specific description for each
> patch).
>
> [...]
>
> --
> Clément B.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


More information about the ffmpeg-devel mailing list