(E-)AC3 decoders comparison

[TDiTP_]

I did some comparison of (E-)AC3 decoders, may be it will be useful.

I. E-AC3 decoders comparison.

Arrangement:

Encoding WAV (PCM) to E-AC3 — Dolby® Media Encoder SE v1.3.8 (from Dolby Media Producer Suite). Preprocessing was disabled, DRC="none", DN=-31dB, target="Standard". Screens of settings. (http://tditp.imgur.com/dolby_media_encoder_settings)
Decoding E-AC3 to WAV (PCM):


libav. Using eac3to 3.24. Output is represented in 24-bit int (default).
eac3to input.ec3 output.wavs -libav -no2ndpass
libav-ffmpeg. Using ffmpeg.exe (SVN-r25870-Sherpya). Output can be represented in 16-bit int only.
ffmpeg -drc_scale 0 -i input.ec3 output.wav
Nero7. Using eac3to 3.24. Output is represented in 24-bit int (default).
eac3to input.ec3 output.wavs -nero
CyberLink. DirectShow's graph: "LAV Splitter → CyberLink Audio Decoder (PDVD10) → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "PowerDVD 10 Mark II 10.0.2701.51". Output is represented in 16-bit int.
I could not turn off the forced mixing to 2.0 inside DS-filter.
Sonic. DirectShow's graph: "File Source (Async.) → Sonic HD Demuxer → Sonic Cinemaster Audio Decoder 4.3.0 → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "Sonic Audio Decoder (4.3.0.169)".
Output is represented in 16-bit int. Decoder has a feature: it always increases the amplitude in ~1,5 times (i.e. +3,54 dB). To be able to compare the WAV with the others,
after each decoding level accounted for accurately calculate and understate, it was done very accurately using CopyAudio (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CopyAudio.html).
ArcSoft. DirectShow' graph: "LAV Splitter → ArcSoft Audio Decoder HD → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "ArcSoft TotalMedia Theatre 3.0.1.190". Output is represented in 16-bit int.
I could not turn off the forced mixing to 2.0 inside DS-filter.

Nero, CyberLink, Sonic and ArcSoft manufactures has been licensed by Dolby Laboratories. (http://www.dolby.com/professional/technology/licensing/licensed-manufacturers.html)

SNR (http://en.wikipedia.org/wiki/Signal-to-noise_ratio) measurement (bigger is better) — CompAudio (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CompAudio.html)
Spectrograms — Sound Forge, Sox.

Results:

I. Scheme 2.0.
Source test1.wav (stereo) was encoded to E-AC3 1536 kbps and then was decoded. Download all streams (http://www.mediafire.com/?qvhxi0y7ptxtrvm).

Average frequency spectrograms: Graphs test1 (http://tditp.imgur.com/average_frequency_graphs_scheme_20eac3_test1).
Time-frequency spectrograms: Graphs test1 (http://tditp.imgur.com/sonograms_scheme_20_eac3_test1).
SNR:
__________________________________________
| SNR (FL), dB | SNR (FR), dB
| |
libav-eac3to | 51.453 | 50.987
libav-ffmpeg | 51.450 | 50.983
nero7 | 51.453 | 52.770
ArcSoft | 51.445 | 52.758
CyberLink | 51.438 | 52.749
Sonic | 51.453 | 52.770
__________________________________________

- All decoders have the same frequency response.
- There are some differences in SNR for FR-channel between libavcodec and other decoders.

Look at the effect of bitrate.
Source test2.wav was encoded to E-AC3 192, 320 and 640 kbps (download all streams (http://www.mediafire.com/?7ci8i0a3tt2xqug)). Streams were decoded with the help of all decoders.

In fact we have:
- Again all decoders have the same frequency response (too many screenshots → don't show)
- In case of 640 kbps we have significant differences in SNR between libavcodec and others:
______________________________________________
192 kbps:
| SNR (FL), dB | SNR (FR), dB
| |
libav-eac3to | 21.496 | 20.785
libav-ffmpeg | 21.496 | 20.785
nero7 | 21.498 | 20.815
ArcSoft | 21.504 | 20.817
CyberLink | 21.498 | 20.814
Sonic | 21.498 | 20.815
______________________________________________
320 kbps:
| SNR (FL), dB | SNR (FR), dB
| |
libav-eac3to | 32.854 | 31.875
libav-ffmpeg | 32.854 | 31.875
nero7 | 32.869 | 32.286
ArcSoft | 32.885 | 32.301
CyberLink | 32.872 | 32.290
Sonic | 32.872 | 32.285
______________________________________________
640 kbps:
| SNR (FL), dB | SNR (FR), dB
| |
libav-eac3to | 50.482 | 41.515
libav-ffmpeg | 50.480 | 41.515
nero7 | 50.464 | 50.018
ArcSoft | 50.522 | 50.056
CyberLink | 50.467 | 50.008
Sonic | 50.474 | 50.015
______________________________________________

II. Scheme 5.1.
Source test5.wav was encoded to E-AC3 1536 kbps (download all streams (http://www.mediafire.com/?tu7ddk1yv8zup8c)). Streams were decoded with the help of four decoders
(I wasn't able to test ArcSoft and Cyberlink because I could not turn off the forced mixing to 2.0 inside DS-filter). Results are shown in the example FC-channel, for other speakers all the same.


Average frequency spectrograms: Graphs test5 (http://tditp.imgur.com/average_frequency_graphs_scheme_51_eac3_test5).
Time-frequency spectrograms: Graphs test5 (http://tditp.imgur.com/sonograms_scheme_51_eac3_test5).
SNR:
___________________________________________________________________________
| SNR(FC) | SNR(FL) | SNR(FR) | SNR(SL) | SNR(SR) | SNR (LFE)
| | | | | |
libav-eac3to | 43.220 | 54.976 | 50.908 | 45.386 | 48.720 | 65.116
libav-ffmpeg | 43.210 | 54.741 | 50.833 | 45.270 | 48.646 | 62.140
nero7 | 43.333 | 54.958 | 57.507 | 52.597 | 57.600 | 65.117
Sonic | 43.308 | 54.964 | 57.433 | 52.577 | 57.806 | 65.117
___________________________________________________________________________

- All decoders have the same frequency response.
- There are serious differences in SNR between libavcodec and Nero, Sonic.

Look at the effect of bitrate.
Source test6.wav (each channel is packed with a 0 dB, action-scene from the movie) was encoded to E-AC3 384, 768 and 1536 kbps (download all streams (http://www.mediafire.com/?jz328u8v8vko88v)).
Streams were decoded with the help of three decoders (i wasn't able to test Sonic because it always increases the level of PCM).

In fact we have:
- Again all decoders have the same frequency response (too many screenshots → don't show)
- There are no significant differences in SNR between decoders:
________________________________________________________________________________________________________________
1536 kbps:

| SNR(FC) | SNR(FL) | SNR(FR) | SNR(SL) | SNR(SR) | SNR (LFE)
| | | | | |
libav-eac3to | 35.295 | 35.910 | 32.606 | 34.226 | 33.600 | 54.511
libav-ffmpeg | 35.295 | 35.910 | 32.606 | 34.226 | 33.600 | 54.487
nero7 | 36.931 | 35.877 | 35.463 | 34.398 | 33.631 | 54.510
________________________________________________________________________________________________________________
768 kbps:

| SNR(FC) | SNR(FL) | SNR(FR) | SNR(SL) | SNR(SR) | SNR (LFE)
| | | | | |
libav-eac3to | 30.972 | 30.351 | 28.666 | 28.293 | 27.321 | 36.118
libav-ffmpeg | 30.972 | 30.351 | 28.666 | 28.293 | 27.321 | 36.118
nero7 | 31.501 | 30.322 | 29.610 | 28.325 | 27.319 | 36.118
________________________________________________________________________________________________________________
384 kbps:

| SNR(FC) |SNR(FL) | SNR(FR) | SNR(SL) | SNR(SR) | SNR (LFE)
| | | | | |
libav-eac3to | 22.630 | 21.100 | 20.440 | 18.961 | 19.222 | 25.299
libav-ffmpeg | 22.630 | 21.100 | 20.440 | 18.961 | 19.222 | 25.299
nero7 | 22.939 | 21.398 | 20.883 | 19.287 | 19.634 | 25.302
________________________________________________________________________________________________________________

Conclusions:

1). Frequency response of libavcodec is the same as frequency response of licensed decoders (ArcSoft, Sonic, Nero and Cyberlink).
2). In some cases libavcodec provides too low SNR for some of the channels. These differences may be significant. Very strange for a predetermined process (bug?).
3). In some cases SNR (libav-eac3to) little more than SNR (libav-ffmpeg). Most likely because libav in eac3to was patched by madshi for decoding to 24-bit (against 16-bit for libav-ffmpeg).

As libavcodec is the only decoder that can ignore DRC [Madshi unable to completely disable the use of DRC in eac3to-Nero (http://forum.doom9.org/showthread.php?p=1404212#post1404212). I can confirm it for E-AC3], it would be nice to get rid of the trouble with SNR. Licensed decoders use the DRC and therefore can not be used for properly decoding, because all the corporate tracks E-AC3 are encoded with DRC (Dolby's recommendation).

[TDiTP_]

II. AC3 decoders comparison.

Arrangement:

Encoding WAV (PCM) to AC3 — DolbyEncoder (SFSE 1.0). Preprocessing was disabled, DRC="none", DN=-31dB.
Decoding AC3 to WAV (PCM):


Azid 1.9. Output is represented in 24-bit int.
azid -d1/0 -oc -F wav24 input.ac3 output.wav
azid -d2/0 -ol,r -F wav24 input.ac3 output.wav
azid -d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr -F wav24 input.ac3 output.wav
liba52. Using NicAudio 2.0.4 / BeHappy as frontend. Downsampling from 32-bit FP to 24-bit Int without dithering.
libav. Using eac3to 3.24. Output is represented in 24-bit int (default).
eac3to input.ac3 output.wavs -libav -no2ndpass
Nero7. Using eac3to 3.24. Output is represented in 24-bit int (default).
eac3to input.ac3 output.wavs -nero
Nero9. DirectShow's graph: "AC3File → Nero Audio Decoder 2 → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "Nero 9 ShowTime 5.2.12.0". Output is represented in 24-bit int.
CyberLink. DirectShow's graph: "AC3File → CyberLink Audio Decoder (PDVD10) → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "PowerDVD 10 Mark II 10.0.2325.51".
Output is represented in 16-bit int. I could not turn off the forced mixing to 2.0 inside DS-filter.
Sonic. DirectShow's graph: "Haali Media Splitter → Sonic Cinemaster Audio Decoder 4.3.0 → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "Sonic Audio Decoder (4.3.0.169)". Output is represented in 16-bit int.
Decoder has a feature: it always increases the amplitude in ~1,5 times (i.e. +3,54 dB).
To be able to compare the WAV with the others, after each decoding level accounted for accurately calculate and understate, it was done very accurately using CopyAudio (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CopyAudio.html).
ArcSoft. DirectShow' graph: "File Source (Async.) → ArcSoft MPEG Demux → ArcSoft Audio Decoder HD → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "ArcSoft TotalMedia Theatre 3.0.1.190".
Output is represented in 16-bit int. I could not turn off the forced mixing to 2.0 inside DS-filter.
Sonic Foundry Soft Encode 1.0 (SFSE). Internal decoder was used.

Nero, CyberLink, Sonic and ArcSoft manufactures has been licensed by Dolby Laboratories. (http://www.dolby.com/professional/technology/licensing/licensed-manufacturers.html)

SNR (http://en.wikipedia.org/wiki/Signal-to-noise_ratio) measurement (bigger is better) — CompAudio (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CompAudio.html)
Spectrograms — Sound Forge, Sox.

Results:

I. Scheme 1.0.
Two different samples were encoded to AC3 96kbps and then were decoded. Source t2.wav was obtained from source t1.wav through the low-pass filter (16kHz). Download test1 (http://www.mediafire.com/?3776m46q8xh6kpw), Download test2 (http://www.mediafire.com/?enq2gk88jp55vqj).


Average frequency spectrograms: Graphs test1 (http://tditp.imgur.com/average_frequency_graphs_scheme_10_test1), Graphs test2 (http://tditp.imgur.com/average_frequency_graphs_scheme_10_test2)
Time-frequency spectrograms: Graphs test1 (http://tditp.imgur.com/sonograms_scheme_10_test1), Graphs test2 (http://tditp.imgur.com/sonograms_scheme_10_test2)

As you can see from two type of graphs, frequency response: liba52 = azid = sfse = cyberlink ≠ libav = nero7 = nero9 = sonic = arcsoft.
SNR:
_____________________________________
| SNR (t1), dB | SNR (t2), dB
| |
Azid | 24.080 | 27.113
liba52 | 24.082 | 27.092
SFSE | 24.076 | 27.072
CyberLink | 24.076 | 27.072
| |
libav | 24.256 | 27.340
nero7 | 24.263 | 27.371
nero9 | 24.237 | 27.335
Sonic | 24.237 | 27.335
ArcSoft | 24.224 | 27.320
_____________________________________

As you can see, decoders can be divided into two groups:
"A" - liba52, azid, sfse, cyberlink.
"B" - libav, nero7, nero9, sonic, arcsoft.

- frequency response of "A" is closer to source than frequency response of "B" (downturn of high frequencies).
- SNR for "B" is a little more than for "A".


Look at the effect of bitrate.
Source t3.wav was encoded to AC3 96, 128 and 192 kbps. Streams were decoded and results are shown in the example of two representatives of groups: libav and liba52 (otherwise too many pictures).
Download test3 (http://www.mediafire.com/?ueojteit73d3w79).


Average frequency spectrograms: Graphs test3 (http://tditp.imgur.com/average_frequency_spectrograms_scheme_10_test3).
Time-frequency spectrograms: Graphs test3 (http://tditp.imgur.com/sonograms_scheme_10_test3).
SNR:
______________________
| SNR (t3), dB
|
96_liba52 | 29.800
96_libav | 29.895
|
128_liba52 | 36.751
128_libav | 36.802
|
192_liba52 | 48.215
192_libav | 48.375
______________________

Again all decoders can be divided into two same groups.

- Again, "B" have a high-frequency decline (usually 13-17 kHz). But! At this sample we can see new thing - "A" have a high-frequency increase relative to the source.
- Again, SNR for "B" is a little more than for "A".
- frequency response for "A" does not depend on the bitrate. Frequency response for "B" depend on the bitrate of AC3.

II. Scheme 2.0.
Again all decoders can be divided into two same groups (Dualmono and Stereo were tested). A total of four samples were tested, you can download test4 (http://www.mediafire.com/?y2pf7hj5nccczxo).
Source t4.wav was encoded to AC3 192 kbps and then was decoded.

Average frequency spectrograms: Graphs test4 (http://tditp.imgur.com/average_frequency_spectrograms_scheme_20_test4).
Time-frequency spectrograms: Graphs test4 (http://tditp.imgur.com/sonograms_scheme_20_test4).
SNR:
_______________________________________
| SNR (FL), dB | SNR (FR), dB
| |
liba52 | 22.335 | 21.761
Azid | 22.334 | 21.757
CyberLink | 22.341 | 21.754
SFSE | 22.33 | 21.761
| |
libav | 22.421 | 21.796
nero7 | 21.697 | 21.028
nero9 | 21.687 | 21.028
Sonic | 21.687 | 21.028
ArcSoft | 22.480 | 21.888
_______________________________________

I. Scheme 5.1.
Again all decoders can be divided into two same groups. A total of two samples were tested, you can download test5 (http://www.mediafire.com/?hjhddyv7oeygb77).
Source t5.wav was encoded to AC3 448 kbps and then was decoded (i wasn't able to test ArcSoft and Cyberlink because I could not turn off the forced mixing to 2.0 inside DS-filter).
Results are shown in the example FC-channel, for other speakers all the same.

Average frequency spectrograms: Graphs test5 (http://tditp.imgur.com/average_frequency_graphs_scheme_51_test5).
Time-frequency spectrograms: Graphs test5 (http://tditp.imgur.com/sonograms_scheme_51_test5).
SNR:
______________________________________________________________________
| SNR(FC) | SNR(FL) | SNR(FR) | SNR(SL) | SNR(SR) | SNR (LFE)
| | | | | |
liba52 | 29.802 | 29.908 | 30.930 | 28.610 | 30.533 | 32.338
Azid | 29.847 | 29.906 | 30.928 | 28.612 | 30.535 | 32.338
SFSE | 29.771 | 29.909 | 30.930 | 28.615 | 30.536 | 32.336
| | | | | |
libav | 30.192 | 29.942 | 30.918 | 28.608 | 30.520 | 32.338
nero7 | 30.221 | 29.942 | 30.954 | 28.678 | 30.579 | 32.338
nero9 | 30.192 | 29.941 | 30.954 | 28.680 | 30.580 | 32.338
Sonic | 30.192 | 29.939 | 30.952 | 28.674 | 30.577 | 32.331
______________________________________________________________________


Conclusions:

Tested decoders can be divided into two groups:

"A" - liba52, azid, sfse, cyberlink.
"B" - libav, nero7, nero9, sonic, arcsoft. UPD: internal decoder of "SurCode for Dolby Digital® 5.1 Encoder and Decoder" (http://www.minnetonkaaudio.com/index.php?option=com_content&view=article&id=51&Itemid=80) was tested. It's belongs to "B".

1). Frequency response of "A" is closer to source than frequency response of "B" (downturn of high frequencies, usually after 13-17 kHz). It's very strange for a predetermined process!
2). There are differences in SNR between decoders (and between groups) but in general they can be considered negligible (i think).

[jruggle]

Conclusions:

Tested decoders can be divided into two groups:

"A" - liba52, azid, sfse, cyberlink.
"B" - libav, nero7, nero9, sonic, arcsoft. UPD: internal decoder of "SurCode for Dolby Digital® 5.1 Encoder and Decoder" (http://www.minnetonkaaudio.com/index.php?option=com_content&view=article&id=51&Itemid=80) was tested. It's belongs to "B".

1). Frequency response of "A" is closer to source than frequency response of "B" (downturn of high frequencies, usually after 13-17 kHz). It's very strange for a predetermined process!
2). There are differences in SNR between decoders (and between groups) but in general they can be considered negligible (i think).

Thank you for doing these tests. They are very thorough. For the AC-3 test I highly suspect that the difference in frequency response is due to dithering of 0-bit mantissas. This is one part of the decoding process that is not narrowly defined in the specification. It says that "any reasonably random sequence may be used" and that the range can be anywhere from +/- 0.5 to +/- 0.75. High frequency coefficients are more likely to be quantized to 0 bits and therefore to require dithering in the decoder.

Also, the internal representation vs. the output sample format (and the conversion process) could be different for the decoders. For example, some decoders may use a 16-bit or 24-bit fixed point representation in the decoder, while others may use floating-point then convert to 24-bit.

[jruggle]

I. E-AC3 decoders comparison.

Conclusions:

1). Frequency response of libavcodec is the same as frequency response of licensed decoders (ArcSoft, Sonic, Nero and Cyberlink).
2). In some cases libavcodec provides too low SNR for some of the channels. These differences may be significant. Very strange for a predetermined process (bug?).
3). In some cases SNR (libav-eac3to) little more than SNR (libav-ffmpeg). Most likely because libav in eac3to was patched by madshi for decoding to 24-bit (against 16-bit for libav-ffmpeg).

As libavcodec is the only decoder that can ignore DRC [Madshi unable to completely disable the use of DRC in eac3to-Nero (http://forum.doom9.org/showthread.php?p=1404212#post1404212). I can confirm it for E-AC3], it would be nice to get rid of the trouble with SNR. Licensed decoders use the DRC and therefore can not be used for properly decoding, because all the corporate tracks E-AC3 are encoded with DRC (Dolby's recommendation).

Thank you. This is very helpful. I will need to analyze the samples you used to figure out what E-AC-3 features they utilize to try to narrow down the issue.

Also, as of a few months ago, Libav can output 24-bit AC-3 and E-AC-3.
example:

ffmpeg -i test.ac3 -drc_scale 0 -acodec pcm_s24le -y test.wav

You can get daily windows autobuilds at http://win32.libav.org/win32/

[TDiTP_]

For the AC-3 test I highly suspect that the difference in frequency response is due to dithering of 0-bit mantissas. This is one part of the decoding process that is not narrowly defined in the specification. It says that "any reasonably random sequence may be used" and that the range can be anywhere from +/- 0.5 to +/- 0.75. High frequency coefficients are more likely to be quantized to 0 bits and therefore to require dithering in the decoder.

Thanks for the explanation (if I understand correctly, about the same you said here (http://forum.doom9.org/showthread.php?p=1315753#post1315753)). So.. AC-3 decoding is not deterministic, it's a pity.


Also, the internal representation vs. the output sample format (and the conversion process) could be different for the decoders. For example, some decoders may use a 16-bit or 24-bit fixed point representation in the decoder, while others may use floating-point then convert to 24-bit.

I can add. If we have "others may use floating-point then convert to 24-bit", then they don't use dithering when FP->Int. Because if dithering is used then every new output would not coincide with the previous, but it is not. I tested serial outputs of each decoder and compared them (byte-in-byte in HexEditor). Outputs of each decoder were the same, except outputs of eac3to-libav - it's because eac3to uses dithering when FP->Int.


ffmpeg -i test.ac3 -drc_scale 0 -acodec pcm_s24le -y test.wav

Thanks, good news. I was waiting for this.

UPD. If you need more samples of E-AC3, let me know.

[geminigod]

Based on these findings, is it not worth messing with Nero 7 in EAC3to for decoding ac3? I tracked down a copy of Nero 7 based on eac3to's recommendation for using Nero Audio Decoder, however, my eac3to is still not seeing Nero 7 when I run:
> eac3to -test
I am wondering if it is even worth troubleshooting why this is if libav is just as capable (or maybe even better if it can ignore DRC)???

[kypec]

I personally never bothered to install Nero 7 for eac3to. What for? Decoding AC3? I've reencoded plethora of DVD or BD files via eac3to:libav and I've yet to find any problem with AC3 -> AAC conversion...

[Ghitulescu]

I would be curious to compare the results with a HW decoder, eg one in an AVR or player in decoding mode (as opposed to bitstreaming, DRC on and off).

[hello_hello]

Based on these findings, is it not worth messing with Nero 7 in EAC3to for decoding ac3? I tracked down a copy of Nero 7 based on eac3to's recommendation for using Nero Audio Decoder, however, my eac3to is still not seeing Nero 7 when I run:
> eac3to -test

Don't you need to add a license key to Nero for the Bluray/HD DVD video plugin in order for it to work? Or am I remembering incorrectly?

[geminigod]

Don't you need to add a license key to Nero for the Bluray/HD DVD video plugin in order for it to work? Or am I remembering incorrectly?


You do. I did. Still not working. I am going to uninstall nero 7 which is useless for me other than that codec I wanted for eac3to. I agree that libav is fine for ac3 decoding, and I have better programs for doing ac3 encoding.

[madshi]

For the AC-3 test I highly suspect that the difference in frequency response is due to dithering of 0-bit mantissas. This is one part of the decoding process that is not narrowly defined in the specification. It says that "any reasonably random sequence may be used" and that the range can be anywhere from +/- 0.5 to +/- 0.75. High frequency coefficients are more likely to be quantized to 0 bits and therefore to require dithering in the decoder.
Your guess was right. I've sent a patch now to both libav and ffmpeg dev mailing lists to optimize the 0-bit mantissa dithering. My patch fixes the high frequency response problem. I'm not sure if the spec has changed, but the latest revision (2012) clearly says that the "optimum" scaling is +/- 0.707. The current libav decoder uses +/- 0.5, which the spec calls "also acceptable". With the "optimum" scaling the high frequency response is similar to azid and liba52.

I will need to analyze the samples you used to figure out what E-AC-3 features they utilize to try to narrow down the issue.
It doesn't look like a "feature" that the libav decoder is missing. Instead it seems to me that one of the E-AC3 frames is decoded totally wrong, which reduces the SNR value that much. 99% of the file are decoded with the same quality as the Nero decoder. It's just a few milliseconds that are somewhat damaged. I've created a Bugzilla bug report for this here:

https://bugzilla.libav.org/show_bug.cgi?id=415

[RRAH]

It doesn't look like a "feature" that the libav decoder is missing. Instead it seems to me that one of the E-AC3 frames is decoded totally wrong, which reduces the SNR value that much. 99% of the file are decoded with the same quality as the Nero decoder. It's just a few milliseconds that are somewhat damaged. I've created a Bugzilla bug report for this here:

https://bugzilla.libav.org/show_bug.cgi?id=415[/QUOTE]


Is that really a problem or is the bug inaudible?

Thanks

[Overdrive80]

Actually, Adobe Audition CC 2014.1 decode ac3, I think that properly. Could be updated these tests with that soft???

[tebasuna51]

I think is inaudible.

[sbnsl]

CyberLink. DirectShow's graph: "LAV Splitter → CyberLink Audio Decoder (PDVD10) → Wav Dest → File Writer" was built in GraphEdit. Decoder is taken from "PowerDVD 10 Mark II 10.0.2701.51". Output is represented in 16-bit int.
I could not turn off the forced mixing to 2.0 inside DS-filter.

How to use CyberLink Audio Decoder (PDVD10) to mono wav?

[hello_hello]

Also, as of a few months ago, Libav can output 24-bit AC-3 and E-AC-3.
example:

ffmpeg -i test.ac3 -drc_scale 0 -acodec pcm_s24le -y test.wav

You can get daily windows autobuilds at http://win32.libav.org/win32/

Anyone know that the default is for drc_scale? I'd tend to assume it's zero, but the docs don't actually say.

[tebasuna51]

Without force -drc_scale 0 the decoder must obey the header field Dialogue normalization.

If Dialogue normalization is -27 dB (many times according to Dolby specs) all channels volume are attenuated by 4 dB.
If Dialogue normalization is -31 dB (like free encoders set by default, or eac3to change) -drc_scale 0 is not needed.