ReplayGain query

[DefineByte]

Am I correct in thinking that ReplayGain works in the same way as the software EQ i.e. it's done using the CPU?

Is there a technical reason why Rockbox couldn't use a player's built-in volume adjustment (is that using the DAC? I don't know) in a sort of optional low precision ReplayGain mode (on compatible outputs)?

It would save significant battery life, would it not?

[baobab68]

I think it does use the CPU. I had a developer tell me that it's not expensive in terms of CPU usage - it only causes one extra "multiply" for each sample - ie multiply the amplitude by the scaling factor represented by the Replaygain value.

I do see your point though, but I don't have the tech knowledge to comment, sorry.

[saratoga]

Am I correct in thinking that ReplayGain works in the same way as the software EQ i.e. it's done using the CPU?

Thats correct.  

Is there a technical reason why Rockbox couldn't use a player's built-in volume adjustment

Because replaygain is a digital adjustment, and must be done prior to loading samples onto the DAC.  RG actually takes each sample and multiplies it by a constant.  You can't do that with a DAC.

It would save significant battery life, would it not?

I don't think replaygain is CPU intensive enough to have a noticeable impact on CPU performance.  Its just 44,100 16 bit multiplies per second.  Thats not very much CPU time.

[mamboman]

good to know that. i find that it's very useful so that i don't have tracks jumping from quiet to loud and all over the place

[Lear]

Is there a technical reason why Rockbox couldn't use a player's built-in volume adjustment (is that using the DAC? I don't know) in a sort of optional low precision ReplayGain mode (on compatible outputs)?

For the "Prevent Clipping" option to work, the volume adjustment has to be done before the samples are scaled/clipped to the final output (which happens before the samples are sent to the DAC). And if you don't use the clip prevention, using Replaygain is likely to reduce any clipping introduced by a lossy encoder.

Besides, it's much easier this way. No need to worry about exactly when a certain sample is played. And using the volume adjustment wouldn't work well when using crossfading.

[Lear]

Because replaygain is a digital adjustment, and must be done prior to loading samples onto the DAC.  RG actually takes each sample and multiplies it by a constant.  You can't do that with a DAC.

Multiplying a stream of samples with a constant is the same as adjusting the volume. Might not be a part of the DAC proper, but...

I don't think replaygain is CPU intensive enough to have a noticeable impact on CPU performance.  Its just 44,100 16 bit multiplies per second.  Thats not very much CPU time.

For the typical stereo track, there are 88,200 32-bit multiplies. Still not that much CPU needed, compared to decompressing the audio.

[DefineByte]

For the Pevent Clipping" option to work, the volume adjustment has to be done before the samples are scaled/clipped to the final output (which happens before the samples are sent to the DAC).

Couldn't you simply fall back to the current way of doing things if the file is found to clip? Most files don't clip do they?

Maybe 'significant' was a bit of a stretch but it would save some. If it was enough to prevent a boost of the CPU (in the right conditions) I would imagine it would be noticeable.

Thanks for all your responses. It's been bugging me for a while. x)

[markun]

Maybe 'significant' was a bit of a stretch but it would save some. If it was enough to prevent a boost of the CPU (in the right conditions) I would imagine it would be noticeable.

You can find out by playing a song with replaygain on and off and checking the difference in boost percentage.

btw, here's an old patch by me to help you a bit if you still want to take this route:

http://130.89.160.166/rockbox/replaygain3.patch

might not apply and/or be the best way of doing it

[DefineByte]

The problem I have with that suggestion is that my eyesight is quite poor and the debug menu reverts to the default tiny font.

Seems I should invest in a decent magnifying glass. xD

[saratoga]

Multiplying a stream of samples with a constant is the same as adjusting the volume.

Provided you have infinate word length sure.  However, for a 16 bit word, this is not the case, which is why replaygain is so useful to reduce clipping.

For the typical stereo track, there are 88,200 32-bit multiplies. Still not that much CPU needed, compared to decompressing the audio.

Forgot about stereo.  However, I believe its just a 16 bit multiply.  At least I know my decoder only puts out a 16 bit sample, unless the playback engine is converting back to 32 bit?

[Lear]

Forgot about stereo.  However, I believe its just a 16 bit multiply.  At least I know my decoder only puts out a 16 bit sample, unless the playback engine is converting back to 32 bit?

I know for certain that the multiplies are 32 bit in Rockbox (I did write the original replaygain code). Most codecs (at least most lossy ones; not sure about the rest) in Rockbox return more than 16 bits, and the dsp does all processing in 32 bits, for simplicity, accuracy and to allow things like clip prevention. The samples are scaled to 16 bit as the final step (with optional dithering).

So, it sounds like the WMA decoder should at some point be modified to return more than 16 bits per sample...

[markun]

So, it sounds like the WMA decoder should at some point be modified to return more than 16 bits per sample...

Done, it now returns 30 bits per sample