I've been experimenting with the ideas of Replay Gain[1] and find that ogg123 doesn't have a way of specifying the scaling applied to replayed samples (like -f in mpg123). Looking at libvorbisfile, I see no function exactly matching this possibly desirable behaviour. ov_read() scales by either 128 (byte output) or 32768 (word output), but there's nothing in between. ov_read_float() outputs floats, which is OK, but means more work in the frontend program. My suspicion is that floats are not used internally by ov_read(), and there would be a speed penalty for using ov_read_float(). Anyone have further thoughts on this? [1] http://privatewww.essex.ac.uk/~djmrob/replaygain/ -- Paul Martin --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
ov_read and ov_read_float both call:
int vorbis_synthesis_pcmout(vorbis_dsp_state *v,float ***pcm);
for ov_read() the data is then coerced into int form.
I think ov_read() is the right place to do the scaling. Doing it inside
the decoding in block.c might make that code yet more complex.
ov_read_float doesn't need to be scaled because very little is lost if
you scale the float data outside that function. It makes a big
difference to scale before coercing into integer data if you're unlucky
enough to have a signal quiet enough to otherwise only use 1% of the
encoding, or worse so loud that it clips.
(or is normalizing taken care of elsewhere that I haven't found yet? if
not, gain-on-input is another feature I'd like to see)
if the prototype for ov_read() is now writ in stone, how about:
long ov_read_gain(OggVorbis_File *vf,char *buffer,int length,
int bigendianp,int word,int sgned,float gain,int
*bitstream)
ov_read() could internally call ov_read_gain(..., 1, ...);
that would save on code, but there _might_ be a speed issue, and maybe
some processor's floating point will be unlucky enough to lose a bit of
accuracy by multiplying everything by 1.0000000...
perhaps a little C-style preprocessor templating, remove the body of
ov_read() into ov_read.h (or .ic if you like)
(I'll make a patch to implement this if I'm not flamed off the list for
it being a gross hack.)
change several lines in ov_read like this one:
val=vorbis_ftoi(src[j]*32768.f);
to this:
val=vorbis_ftoi(src[j]*32768.f TIMES_GAIN);
#define TIMES_GAIN * gain
ov_read_gain(...) {
#include "ov_read.h"
}
#undefine TIMES_GAIN
#define TIMES_GAIN
ov_read(...) {
#include "ov_read.h"
}
#undefine TIMES_GAIN
On Thursday, January 3, 2002, at 05:03 AM, Paul Martin wrote:
> I've been experimenting with the ideas of Replay Gain[1] and find that
> ogg123 doesn't have a way of specifying the scaling applied to
> replayed samples (like -f in mpg123).
>
> Looking at libvorbisfile, I see no function exactly matching this
> possibly desirable behaviour.
>
> ov_read() scales by either 128 (byte output) or 32768 (word output),
> but there's nothing in between.
>
> ov_read_float() outputs floats, which is OK, but means more work in the
> frontend program.
>
> My suspicion is that floats are not used internally by ov_read(), and
> there would be a speed penalty for using ov_read_float().
>
> Anyone have further thoughts on this?
>
> [1] http://privatewww.essex.ac.uk/~djmrob/replaygain/
> --
> Paul Martin
>
>
[insert clever signoff here]
Brian Olson http://bolson.org/
<p>--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
> My suspicion is that floats are not used internally by ov_read(), and > there would be a speed penalty for using ov_read_float().Vorbis is natively float based. ov_read_float will be quite a bit faster than ov_read, since it won't have the huge float->int conversion, etc (note that on x86, the float->int conversion is in assembler so it's pretty fast). ov_read() 's conversion is still one of the slower functions on decode, especially on PPC it seems. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thu, Jan 03, 2002 at 01:03:11PM +0000, pm wrote:> I've been experimenting with the ideas of Replay Gain[1] and find that > ogg123 doesn't have a way of specifying the scaling applied to > replayed samples (like -f in mpg123).> ov_read() scales by either 128 (byte output) or 32768 (word output), > but there's nothing in between. > > ov_read_float() outputs floats, which is OK, but means more work in the > frontend program.Further to this I've "used the source" and made an ogg-to-raw pipeline, with scaling. A suggestion for if anyone's considering making an ov_read_scale(), make the scaling factor a float, with unity gain being 1.0. Then you can calculate scale=32768.f*scale_factor (or scale=128.f*scale_factor) and use that instead of the constants in a copy of ov_read. Something like: float scale = (word==1?128.f:32768.f)*scale_factor; Or if you want to use decibels, float scale = (word==1?128.f:32768.f)*pow(10.0,decibel/20.0); I also made another program to calculate the replaygain directly from an ogg stream using ov_read_float(), which has the advantage that it calculates correctly even for streams that would go into clipping using ov_read. I have one produced by "libVorbis I 20010813" which peaks at 35226 (1.075021 * FS, or +0.628 dBFS). Why am I doing all this? I've written a playout system for a volunteer FM radio station which is likely to be on for 14 days in mid February. If I couldn't get some sort of level equalisation between tracks, I'd have had to be encoding everything to mp3 (mpg123 has the -f option). -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home) --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.