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. |
24th November 2008, 14:19 | #7121 | Link | |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
http://sox.sourceforge.net/ I will post my results when I have a better understanding of their correctness... I also want to compare it by earing, but I'm currently in the process of upgrading my audiogear... maybe I should post first the technical objective tests and let the subjective tests to later?... |
|
24th November 2008, 15:52 | #7123 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
What leads you to that conclusion? Have you compared the original SSRC results or the latest eac3to implementation?
The preliminary graphs of the latest eac3to SSRC resampling implementation (v2.78) look almost identical to the SOX graphs. Have a look for yourself: And these may not the final results yet. I might be able to further improve noise floor (2nd image). |
24th November 2008, 17:26 | #7125 | Link |
Registered User
Join Date: Oct 2006
Posts: 303
|
I know this a stupid question, but I sometimes get confused about negative delays. If I have a video w/AC3 audio and eac3to reports -100ms delay, then basically eac3to will just drop the first three audio frames of the AC3 stream(around 96ms). Is that a correct assumption, and if it was 100ms delay, then it would add three 32ms frames at the start.
Would that be a correct assumption? |
24th November 2008, 17:29 | #7126 | Link |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
My first tests. Since that website results are almost identical it made me think that my tests could show something interesting...
I have used the original SSRC HQ version. I have done this a few weeks back. I will try with your implementation, I hope it surpasses SOX!... |
24th November 2008, 17:34 | #7127 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Yes.
Do you have a software (free to share) which can produce similar graphs to those on that website? I know how to create such a sweep graph, but I don't know how to get the other ones, especially the 2nd one. |
24th November 2008, 22:45 | #7128 | Link |
Registered User
Join Date: Mar 2006
Posts: 1,538
|
I'm now experiencing errors when converting the follwing DTS files to AC3.
http://www.sendspace.com/file/meghs0 Code:
eac3to v2.78 command line: eac3to "C:\Personal\Videos\dts.hires.71.24.96.2604.dtshd" "C:\Personal\Videos\dts.hires.71.24.96.2604.ac3" ------------------------------------------------------------------------------ DTS Hi-Res, 7.1 channels, 0:00:16, 24 bits, 2559kbps, 96khz (core: DTS-ES, 5.1 channels, 0:00:16, 24 bits, 1509kbps, 48khz) AC3 encoding doesn't support back channels. Will mix them into the surround. Decoding with ArcSoft DTS Decoder... Mixing surround channels... Loading white noise (needed for dithering)... Encoding AC3 <640kbps> with libAften... Initialization of the AC3 encoder failed. Aborted at file position 16384. eac3to v2.78 command line: eac3to "C:\Personal\Videos\nature01.50ch.96kHz.24bit.ma.dtshd" "C:\Personal\Videos\nature01.50ch.96kHz.24bit.ma.ac3" ------------------------------------------------------------------------------ DTS Master Audio, 5.0 channels, 24 bits, 96khz (core: DTS, 5.0 channels, 24 bits, 1509kbps, 48khz) Decoding with ArcSoft DTS Decoder... The AC3 encoder received a non-supported data format (pcm, 5, 24, -). Aborted at file position 16384. eac3to v2.78 command line: eac3to "C:\Personal\Videos\nature02.50ch.96kHz.24bit.ma.dtshd" "C:\Personal\Videos\nature02.50ch.96kHz.24bit.ma.ac3" ------------------------------------------------------------------------------ DTS Master Audio, 5.0 channels, 24 bits, 96khz (core: DTS, 5.0 channels, 24 bits, 1509kbps, 48khz) Decoding with ArcSoft DTS Decoder... The AC3 encoder received a non-supported data format (pcm, 5, 24, -). Aborted at file position 16384. Last edited by rack04; 24th November 2008 at 22:47. |
25th November 2008, 01:00 | #7129 | Link | |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
Do you want to keep this discussion in this thread? I think it would be a better idea starting a new thread just about resamplers... If you want I can start it and post my first test results... |
|
25th November 2008, 01:59 | #7130 | Link | ||
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,890
|
Quote:
Code:
eac3to "dts.hires.71.24.96.2604.dtshd" xx.ac3 -resampleTo48000 Quote:
Code:
eac3to "nature02.50ch.96kHz.24bit.ma.dtshd" stdout.wav -resampleTo48000 | Aften -b 640 - xx.ac3
__________________
BeHappy, AviSynth audio transcoder. Last edited by tebasuna51; 25th November 2008 at 02:02. |
||
25th November 2008, 08:46 | #7131 | Link | |
Spielberger
Join Date: Feb 2005
Posts: 838
|
As stated earlier in this thread I tried to concatenate AVCHD clips from my Sony Cam using eac3to and its gap/overlapping feature.
But concatenating clips results in increasing negative audio delay. First demux log from eac3to: Quote:
Start Delay in all clips is 1:040 Clip1 last Video PTS: 45:720 correct Start Delay: 44:680 Duration (adding duration of last video frame): 44:720 last Audio PTS: 45:744 correct Start Delay: 44:704 Duration (adding duration of last audio frame): 44:736 16 ms Clip2 last Video 1.00:800 = 59:760 = 59:800 last Audio 1.00:816 = 59:776 = 59:808 8 ms Clip3 last Video 12:440 = 11:400 = 11:440 last Audio 12:464 = 11:424 = 11:456 16 ms Clip4 last Video 1.04:440 = 1.03:400 = 1.03:440 last Audio 1.04:464 = 1.03:424 = 1.03:456 16 ms .... .... So I assume these differences results in increasing delay. |
|
25th November 2008, 09:39 | #7132 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Argh, will fix that in the next build. For now you can simply delete the whole "plugin" folder. It's not needed yet, anyway.
Quote:
Quote:
Quote:
The big question is whether the video in your clips is encoded as single interlaced fields or as interlaced frames? In the first case a video field is 20ms long, in the 2nd case the frame is 40ms long. But now that I think about it, I think eac3to's gap/overlap correction doesn't properly detect these cases. I think for an interlaced stream (regardless of whether the stream is encoded as fields or frames) eac3to always calculates with only 20ms. Which is not correct. But still the results you get could be correct if your stream consists of single encoded fields, only. Is that the case? |
|||
25th November 2008, 12:21 | #7133 | Link |
Registered User
Join Date: Dec 2006
Posts: 202
|
Is it correct that eac3to does not detect DD+ tracks in M2TS files (streamtype == 0x84)? Also it seems that a DD+ track on BD has a DD core inside, just like TrueHD. The PS3 shows a 640kbps 5.1 DD track when playing the file with a 7.1 DD+ track.
Last edited by evdberg; 25th November 2008 at 12:24. |
25th November 2008, 12:45 | #7134 | Link | |
Spielberger
Join Date: Feb 2005
Posts: 838
|
Quote:
Duration of clips is always a multiple of 40 ms (PAL). An example of such a stream is in post #7054 |
|
25th November 2008, 13:23 | #7135 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Ok, good to know. But how is it done with 60i video and movie content? I guess with 60i video there are also always 2 fields for one PTS timestamp? So I'd have to use 33.366ms, right? How about movies with pulldown flags? 41.70833ms or 33.366ms? |
|
25th November 2008, 13:46 | #7136 | Link |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
When resampling a 16 bit audio file the result should not be also a 16 bit audio file? eac3to is giving me a 24 bit audio file...
Here is my log: Code:
eac3to v2.78 command line: eac3to white44.1_16.wav white44.16_eac3to.wav -resampleTo48000 ------------------------------------------------------------------------------ WAV, 2.0 channels, 0:00:10, 16 bits, 1411kbps, 44.1khz Reading WAV... Resampling to 48khz... Reducing depth from 64 to 24 bits... Writing WAV... Loading white noise (needed for dithering)... Creating file "white44.16_eac3to.wav"... The original audio track has a constant bit depth of 16 bits. The processed audio track has a constant bit depth of 24 bits. eac3to processing took 1 second. Done. |
25th November 2008, 13:51 | #7137 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Resampling is done in 64bit floating point. If you want to end up with a 16bit audio track, use the "-down16" parameter. But even downconverting to 24bit already reduces quality. If you want "full" quality (I mean best resampling comparison graphs) you should use "-down32" (32bit PCM) or "-full" (64bit floating point). The "sweep" SSRC High Precision graph on the resampling comparison website looks only that bad because the SSRC standalone tool doesn't support 32bit PCM output. The dithering down to 24bit is responsible for the dark blue background in that graph.
|
25th November 2008, 17:27 | #7138 | Link | |
Registered User
Join Date: Dec 2006
Posts: 202
|
Quote:
|
|
25th November 2008, 17:36 | #7139 | Link | |
Registered User
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
|
Quote:
Last edited by nautilus7; 25th November 2008 at 17:38. |
|
25th November 2008, 18:44 | #7140 | Link | |
Registered User
Join Date: Dec 2006
Posts: 202
|
Quote:
I have that one only on HD-DVD ... |
|
Tags |
eac3to |
Thread Tools | Search this Thread |
Display Modes | |
|
|