lear
New Member
Posts: 17 
|
Post by lear on Dec 28, 2014 10:45:51 GMT -5
Hi,
When playing a track with positive ReplayGain (+3.45 dB in this case), the output can be distorted. It should clip (and handled by the limiter, as I understand it), which is mostly inaudible (to my ears at least), but instead there is clearly audible distortion. I suspect that rather than clip, calculations overflow so that numbers change sign, before the limiter see the samples.
Equalizer and other effects disabled or set to 0. ReplayGain and limiter enabled. I've heard it for one track so far, in AAC (MP4) and FLAC versions. (I haven't looked for other tracks yet.)
Tested on GoneMAD 1.6.7 and 1.9.10.
|
|
|
|
Post by GoneMAD on Dec 28, 2014 12:52:20 GMT -5
Hi, When playing a track with positive ReplayGain (+3.45 dB in this case), the output can be distorted. It should clip (and handled by the limiter, as I understand it), which is mostly inaudible (to my ears at least), but instead there is clearly audible distortion. I suspect that rather than clip, calculations overflow so that numbers change sign, before the limiter see the samples. Equalizer and other effects disabled or set to 0. ReplayGain and limiter enabled. I've heard it for one track so far, in AAC (MP4) and FLAC versions. (I haven't looked for other tracks yet.) Tested on GoneMAD 1.6.7 and 1.9.10. yup its a flaw with the design of the audioengine. Replaygain is applied before it hits the EQ so its clipped before ever getting to limiter. 2.1 is going to mostly be audioengine improvements so I plan on addressing it then. When designing the engine i was under the impression replaygain would never boost past the point of clipping the audio(it seems extremely stupid that it does this) |
|
lear
New Member
Posts: 17
|
Post by lear on Dec 28, 2014 14:17:58 GMT -5
yup its a flaw with the design of the audioengine. Replaygain is applied before it hits the EQ so its clipped before ever getting to limiter. 2.1 is going to mostly be audioengine improvements so I plan on addressing it then. When designing the engine i was under the impression replaygain would never boost past the point of clipping the audio(it seems extremely stupid that it does this) Well, the point is that it isn't clipped, it overflows (or something), causing really bad sound. I tried applying the same gain manually, in an audio editor, and I couldn't hear any distortion from the clipping. If GoneMAD had a decode to file command, it would be easy to see what's going on. By the way, if the audio engine works in a higher resolution than the "target" hardware resolution, applying gain before the EQ isn't a problem ( Rockbox works like this, both regarding resolution and applying gain before the EQ). As for boosting past clipping point, that's why the *_PEAK tags exist, so that the decoder can, if configured to do so, avoid clipping. It is part of the specification really. |
|
|
|
Post by GoneMAD on Dec 28, 2014 17:02:15 GMT -5
yup its a flaw with the design of the audioengine. Replaygain is applied before it hits the EQ so its clipped before ever getting to limiter. 2.1 is going to mostly be audioengine improvements so I plan on addressing it then. When designing the engine i was under the impression replaygain would never boost past the point of clipping the audio(it seems extremely stupid that it does this) Well, the point is that it isn't clipped, it overflows (or something), causing really bad sound. I tried applying the same gain manually, in an audio editor, and I couldn't hear any distortion from the clipping. If GoneMAD had a decode to file command, it would be easy to see what's going on. By the way, if the audio engine works in a higher resolution than the "target" hardware resolution, applying gain before the EQ isn't a problem ( Rockbox works like this, both regarding resolution and applying gain before the EQ). As for boosting past clipping point, that's why the *_PEAK tags exist, so that the decoder can, if configured to do so, avoid clipping. It is part of the specification really. i appreciate the feedback but seeing as i wrote the audioengine, im fully aware of where the issue lies. The DSP works in 32bit but the decoders all output 16bit. Up until lollipop only 16bit output was supported so there really was no reason to rearchitect everything for the few formats thats supported 24/32bit. The decoders output at 16 bit.. in the case of higher res flac they are resampled in the decoder (by decoder i mean the wrapper in gmmp's engine over).. this is also where the replaygain is applied. You might be right about it not clipping and is probably just overflowing which gives weird artifacts. As i mentioned before i was under the assumption that RG would never boost it past the dynamic range of the file.. which i was wrong about.. so without looking at the code i wouldnt be surprised if i didnt put in any overflow protection in the decoders.. the DSP definitely has it. Anyway.. the audio gets corrupted before it even hits the DSP. Moving the application of RG to the DSP (when i said EQ before i meant DSP in general as the EQ is just one of the effects applied in the dsp pipeline) would allow the limiter to do its thing to prevent the clipping (since the audio is in 32bit) Since 5.0 supports 24 bit output there is significant rearchitecting that needs to be done along with moving the RG processing to a portion of the pipeline where its not limited by being 16bit. This is all planned for 2.1 |
|
lear
New Member
Posts: 17
|
Post by lear on Dec 29, 2014 4:51:28 GMT -5
The DSP works in 32bit but the decoders all output 16bit. Up until lollipop only 16bit output was supported so there really was no reason to rearchitect everything for the few formats thats supported 24/32bit. The decoders output at 16 bit.. in the case of higher res flac they are resampled in the decoder (by decoder i mean the wrapper in gmmp's engine over).. this is also where the replaygain is applied. Thanks for the explanation. I worked a bit on the audio engine in Rockbox when I added ReplayGain support, so I'm familiar with this kind of stuff. I'd appreciate if you could take a look at this before the bigger changes planned for 2.1, as it is a bit of a deal-killer for me (even if it doesn't happen very often  ). |
|
|
|
Post by GoneMAD on Dec 29, 2014 14:06:35 GMT -5
The DSP works in 32bit but the decoders all output 16bit. Up until lollipop only 16bit output was supported so there really was no reason to rearchitect everything for the few formats thats supported 24/32bit. The decoders output at 16 bit.. in the case of higher res flac they are resampled in the decoder (by decoder i mean the wrapper in gmmp's engine over).. this is also where the replaygain is applied. Thanks for the explanation. I worked a bit on the audio engine in Rockbox when I added ReplayGain support, so I'm familiar with this kind of stuff. I'd appreciate if you could take a look at this before the bigger changes planned for 2.1, as it is a bit of a deal-killer for me (even if it doesn't happen very often ). its not going to happen until 2.1 Fixing it involves redesigning a good portion of the engine, which is major work and not something im doing until 2.0 is finished |
|
lear
New Member
Posts: 17
|
Post by lear on Dec 30, 2014 3:30:03 GMT -5
I'd appreciate if you could take a look at this before the bigger changes planned for 2.1, as it is a bit of a deal-killer for me (even if it doesn't happen very often ). its not going to happen until 2.1 Fixing it involves redesigning a good portion of the engine, which is major work and not something im doing until 2.0 is finished Just to be clear about what I meant: Changing how ReplayGain is applied, so the result is properly clipped to 16 bits, rather than overflowing in some way. That should be possible to do without a big redesign (a few lines of code should be enough). |
|
|
|
Post by GoneMAD on Dec 30, 2014 11:35:42 GMT -5
its not going to happen until 2.1 Fixing it involves redesigning a good portion of the engine, which is major work and not something im doing until 2.0 is finished Just to be clear about what I meant: Changing how ReplayGain is applied, so the result is properly clipped to 16 bits, rather than overflowing in some way. That should be possible to do without a big redesign (a few lines of code should be enough). that i can do. I just glanced at the code and its definitely an overflow thats happening could you email one of your files that has artifacts to gonemadsoftware@gmail.com so i can use to test |
|
|
|
Post by GoneMAD on Jan 5, 2015 23:28:41 GMT -5
turns out some of the decoders actually did have the clipping already, but opensl (mp4/aac), flac, and ogg vorbis did not have it. Next beta update will have it fixed
|
|
lear
New Member
Posts: 17
|
Post by lear on Jan 15, 2015 3:24:57 GMT -5
turns out some of the decoders actually did have the clipping already, but opensl (mp4/aac), flac, and ogg vorbis did not have it. Next beta update will have it fixed Many thanks. ReplayGain seem to work fine now (no distortions in the track that caused the report, as well as a few other tracks I've played so far). However, it seems the 1.9.11 update broke the equalizer.  Any non-zero band causes a slight buzzing noise, even when using negative gains (and more non-zero bands causes more buzzing). One interesting detail: this is with OpenSL enabled (on a Nexus 5); if I disable OpenSL (and restart GoneMAD), the noise is much louder. |
|
|
|
Post by GoneMAD on Jan 15, 2015 7:45:10 GMT -5
yeah in the process of fixing replaygain i rebuilt the audioengine with google's latest native build tools which apparently broke the DSP (since i have a new dev machine i had gotten the latest tools). I unfortunately have to revert to an older version of the engine (which will remove the RG fix) until i can sit down and figure out why the dsp broke. Im pushing that update in a few
|
|
|
|
Post by GoneMAD on Jan 21, 2015 8:16:04 GMT -5
alright this fix will be back into the next build. Turns out something about google's latest NDK causes the eq distortion.. I went to a slightly older version and rebuilt and everything sounded fine
|
|
lear
New Member
Posts: 17
|
Post by lear on Jan 30, 2015 7:11:58 GMT -5
Thanks, the "bad" track plays back fine now (in 1.9.13).
|
|
).
Any non-zero band causes a slight buzzing noise, even when using negative gains (and more non-zero bands causes more buzzing). One interesting detail: this is with OpenSL enabled (on a Nexus 5); if I disable OpenSL (and restart GoneMAD), the noise is much louder.