Feature request: Add DRC parameter to FFAudioSource()

[tebasuna51]

All players have a option to override the Dynamic Range Compression included in some AC3 files.
Also ffmpeg have the parameter -drc_scale 0

But with FFAudioSource() we can't override the compression and the decoded volume don't match the source volume when DRC data is present.
This is a big problem to transcode audio.

Attached sample files encoded with DRC: Film Standard and DRC: None
The film file have only a
Samples.zip
Dynamic Range Compression min/max : -6,59 / 3,52 dB
but DRC can go until -24/+24 dB

See also https://forum.doom9.org/showthread.php?p=1945716#post1945716

[TbtBI]

Thanks for the fast implementation of avs+ properties, @myrsloik.

Can the same be done with drc_scale patch/arg?

I know you are aware of this doom9 post. StvG builds have reverted back commits and they are using the old way of how ffms2 works, and that's why his other patches cannot be incorporated, right? Cannot something be done to eliminate the regression of the upstream builds compared to StvG builds? From the seeking tests I saw in doom9 (I tested with few other samples too) between the StvG builds and the official one, StvG builds are at least good as the official one. It would be great if the upstream builds are at least good as those custom builds.

[myrsloik]

Nope, drc would require breaking the ABI unless I think of something really clever and I don't think it's worth it. Are there any other formats with optional information in the bitstream that may or may not be applied and the standard says the user should be able to choose? I can't think of any.

[TbtBI]

Thanks for your time.

[myrsloik]

I am however experimenting with it in BestAudioSource so maybe try that once it's updated

[TbtBI]

Tried BestAudioSource (50f514c, compiled with ffmpeg 4.4) but drc_scale does nothing - set it to 0/1/3 gives identical output.

[myrsloik]

Try now, I got misled by the horribly broken d9 patches

[myrsloik]

Implemented in ffms2 as well. No actual testing done yet.

[TbtBI]

Tried 0461d80 but the output is still identical for drc_scale=0/1/3.
Btw drc_scale=0/1/3 is ok when using ffms2 ver from doom9.

[myrsloik]

Are you sure you're testing with an appropriate file? I used comp.exe with bas and got different results. Also audibly different.

[TbtBI]

Tested with this sample and used avs+.
https://imgbox.com/g/3um0zPkG1z - check these images with waveform. Also used ffmpeg to load the avs script and save the audio as wav - wav files from bestaudio drc_scale=x always have identical hash but these from ffms2 with different drc_scale values have different hashes.

Tried upstream ffms2 (0753759) - it's ok. Thanks.

Btw does ffms2 audio have lower precision when decoding compared to bestaudio/ffmpeg? Asking because you can see from the images in the above gallery (ffms2 drc_scale 0 and bestaudio drc_scale x) that there is a difference and ffms2 output looks like having rounding error? bestaudio drc_scale x matches the output of ffmpeg -drc_scale 0 -i ...

[myrsloik]

Now I know why, I forgot to pass on the new options to BAS when using it from Avisynth but not VS. Try again and be amazed... maybe.

[myrsloik]

Btw, the decode precision is the same and any differences are more likely to be cause by seeking or something similar in FFMS2. I guess...

[TbtBI]

BAS is ok now too. Thanks.

Btw, the decode precision is the same and any differences are more likely to be cause by seeking or something similar in FFMS2. I guess...

LWLibavAudioSource gives identical output to FFAudioSource for this frame. Should BAS/ffmpeg result be considered as more precise result than LSMASHSource/FFMS2 in this case?

[myrsloik]

Yes, BAS and FFmpeg are definitely the reference here since both do simple linear decoding of the whole file. It's still odd that LSMASHSource/FFMS2 has exactly the same deviation. If anything I'd expect them to be slightly different.

[TbtBI]

The LSMASHSource/FFMS2 output is not only visibly identical (with waveform) but the hashes match too.
Anyway, thanks for the info.