Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th June 2011, 06:10   #1  |  Link
TDiTP_
Registered User
 
Join Date: Jul 2010
Location: Siberia
Posts: 50
(E-)AC3 decoders comparison

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

I. E-AC3 decoders comparison.

Arrangement:
Code:
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.
Decoding E-AC3 to WAV (PCM):
  1. libav. Using eac3to 3.24. Output is represented in 24-bit int (default). eac3to input.ec3 output.wavs -libav -no2ndpass
  2. 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
  3. Nero7. Using eac3to 3.24. Output is represented in 24-bit int (default). eac3to input.ec3 output.wavs -nero
  4. 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.
  5. 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.
  6. 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. SNR measurement (bigger is better) — CompAudio Spectrograms — Sound Forge, Sox.
Results:
Code:
I. Scheme 2.0.
Source test1.wav (stereo) was encoded to E-AC3 1536 kbps and then was decoded. Download all streams.
  1. Average frequency spectrograms: Graphs test1.
  2. Time-frequency spectrograms: Graphs test1.
  3. 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). 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). 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.
  1. Average frequency spectrograms: Graphs test5.
  2. Time-frequency spectrograms: Graphs test5.
  3. 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). 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. 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).

Last edited by TDiTP_; 25th June 2011 at 15:46. Reason: typo
TDiTP_ is offline   Reply With Quote
Old 18th June 2011, 08:45   #2  |  Link
TDiTP_
Registered User
 
Join Date: Jul 2010
Location: Siberia
Posts: 50
II. AC3 decoders comparison.

Arrangement:
Code:
Encoding WAV (PCM) to AC3 — DolbyEncoder (SFSE 1.0). Preprocessing was disabled, DRC="none", DN=-31dB.
Decoding AC3 to WAV (PCM):
  1. 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
  2. liba52. Using NicAudio 2.0.4 / BeHappy as frontend. Downsampling from 32-bit FP to 24-bit Int without dithering.
  3. libav. Using eac3to 3.24. Output is represented in 24-bit int (default). eac3to input.ac3 output.wavs -libav -no2ndpass
  4. Nero7. Using eac3to 3.24. Output is represented in 24-bit int (default). eac3to input.ac3 output.wavs -nero
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Sonic Foundry Soft Encode 1.0 (SFSE). Internal decoder was used.
Nero, CyberLink, Sonic and ArcSoft manufactures has been licensed by Dolby Laboratories. SNR measurement (bigger is better) — CompAudio Spectrograms — Sound Forge, Sox.
Results:
Code:
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, Download test2.
  1. Average frequency spectrograms: Graphs test1, Graphs test2
  2. Time-frequency spectrograms: Graphs test1, Graphs test2 As you can see from two type of graphs, frequency response: liba52 = azid = sfse = cyberlink ≠ libav = nero7 = nero9 = sonic = arcsoft.
  3. 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.
  1. Average frequency spectrograms: Graphs test3.
  2. Time-frequency spectrograms: Graphs test3.
  3. 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. Source t4.wav was encoded to AC3 192 kbps and then was decoded.
  1. Average frequency spectrograms: Graphs test4.
  2. Time-frequency spectrograms: Graphs test4.
  3. 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. 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.
  1. Average frequency spectrograms: Graphs test5.
  2. Time-frequency spectrograms: Graphs test5.
  3. 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" 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).

Last edited by tebasuna51; 7th December 2012 at 09:04.
TDiTP_ is offline   Reply With Quote
Old 18th June 2011, 18:51   #3  |  Link
jruggle
Registered User
 
Join Date: Jul 2006
Posts: 276
Quote:
Originally Posted by TDiTP_ View Post
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" 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 is offline   Reply With Quote
Old 18th June 2011, 18:59   #4  |  Link
jruggle
Registered User
 
Join Date: Jul 2006
Posts: 276
Quote:
Originally Posted by TDiTP_ View Post
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. 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:
Code:
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/

Last edited by jruggle; 18th June 2011 at 19:04. Reason: added link to win32 builds
jruggle is offline   Reply With Quote
Old 18th June 2011, 19:56   #5  |  Link
TDiTP_
Registered User
 
Join Date: Jul 2010
Location: Siberia
Posts: 50
Quote:
Originally Posted by jruggle
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). So.. AC-3 decoding is not deterministic, it's a pity.

Quote:
Originally Posted by jruggle
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.

Quote:
Originally Posted by jruggle
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.

Last edited by TDiTP_; 18th June 2011 at 21:23.
TDiTP_ is offline   Reply With Quote
Old 16th January 2012, 01:06   #6  |  Link
geminigod
Registered User
 
Join Date: Mar 2011
Posts: 34
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)???
geminigod is offline   Reply With Quote
Old 16th January 2012, 05:51   #7  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 820
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...
kypec is offline   Reply With Quote
Old 16th January 2012, 08:49   #8  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,560
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).
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 16th January 2012, 13:33   #9  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,579
Quote:
Originally Posted by geminigod View Post
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?
hello_hello is offline   Reply With Quote
Old 19th January 2012, 10:11   #10  |  Link
geminigod
Registered User
 
Join Date: Mar 2011
Posts: 34
Quote:
Originally Posted by hello_hello View Post
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.
geminigod is offline   Reply With Quote
Old 5th January 2013, 12:32   #11  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,069
Quote:
Originally Posted by jruggle View Post
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.

Quote:
Originally Posted by jruggle View Post
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
madshi is offline   Reply With Quote
Old 15th October 2014, 07:42   #12  |  Link
RRAH
Registered User
 
Join Date: Mar 2014
Posts: 13
EAC3-Decoding

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
RRAH is offline   Reply With Quote
Old 15th October 2014, 13:16   #13  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Actually, Adobe Audition CC 2014.1 decode ac3, I think that properly. Could be updated these tests with that soft???
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite

Last edited by Overdrive80; 15th October 2014 at 15:36.
Overdrive80 is offline   Reply With Quote
Old 15th October 2014, 15:30   #14  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,341
I think is inaudible.
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 20th May 2018, 10:30   #15  |  Link
sbnsl
Registered User
 
Join Date: May 2018
Posts: 1
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?
sbnsl is offline   Reply With Quote
Reply

Tags
comparison, decoders, e-ac3, eac3

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.