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 5th October 2007, 11:22   #1041  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,170
made a 21,4mb sample from the letters trueHD track (couldnt get to press cancel in evodemux any faster :P)
used eac3to conversion to test 'eac3to letters.thd letters.flac' and got the information that this track contains more than 16-bit of information.
flac size is 52,5mb

http://www.megaupload.com/?d=P5OV5GZP

btw. is the information for trueHD tracks that evodemux gives in the VTI window (quantization field) regarding their bit depth always accurate? or does it always show trueHD tracks with 24-bit, even though they only are 'real' 16-bit tracks sometimes?

Last edited by Thunderbolt8; 5th October 2007 at 11:28.
Thunderbolt8 is offline   Reply With Quote
Old 5th October 2007, 11:35   #1042  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,419
Quote:
Originally Posted by Thunderbolt8 View Post
im not quite sure whether I understood this correctly, are you saying that converted eac3 -> ac3 track is now 32 or 5.33ms too long (which value is right)?
Always the ac3 is 5.33 ms. delayed, but long is any value between 5.33 and 37.33 ms.

Example: we have a source 59 ms. long, after the delay we have 64.33 ms., we need 3 frames (3 x 32 ms = 96 ms) then is 37 ms. too long.
tebasuna51 is offline   Reply With Quote
Old 5th October 2007, 11:51   #1043  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by Thunderbolt8 View Post
made a 21,4mb sample from the letters trueHD track (couldnt get to press cancel in evodemux any faster :P)
used eac3to conversion to test 'eac3to letters.thd letters.flac' and got the information that this track contains more than 16-bit of information.
flac size is 52,5mb
Thanks for the sample. Here's what I'm getting on my PC:

Code:
C:\Desktop>c:\sources\eac3to\eac3to letters.thd letters.flac
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
The following tasks are executed now. Please wait...
- remove Dialog Normalization information
- muxing TrueHD track into temp evo file
Decoding TrueHD track to raw. Please wait...
Checking raw data bitdepth. Please wait...
This TrueHD track contains only 16 bit of information.
The zero bytes were successfully removed from the raw file.
Encoding the raw file to FLAC. Please wait...

Done.
letters.thd: 21.2MB
letters.flac: 18.5MB

I've no idea why this doesn't seem to work on your PC!!! Maybe you have a different version of the TrueHD decoder compared to mine? Maybe yours is applying DRC?

Quote:
Originally Posted by Thunderbolt8 View Post
btw. is the information for trueHD tracks that evodemux gives in the VTI window (quantization field) regarding their bit depth always accurate? or does it always show trueHD tracks with 24-bit, even though they only are 'real' 16-bit tracks sometimes?
I'm not sure. The best hint is the file size. If the TrueHD file is smaller than 2GB, it's most probably a 16bit track.
madshi is offline   Reply With Quote
Old 5th October 2007, 12:00   #1044  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,170
trueHD filesize is 1.32GB

allright, again how can I check all my filters (nero, sonic) such to be absolutely sure they are the same/right ones you also use?
theres should be at least no mistake in the eac3to directory, as I always overwrite the old files with the new ones.
and eac3to is also not complaining that a filter is missing or something like that. but maybe I got an old version of something somwhere :S

LOL I got it
checked the nero product setup and beside that HDDVD/blue-ray plugin there were also a BD test and HDDVD test plugin installed. I remember once having installed them few days ago, because I wasnt sure if that hddvd/blue-ray plugin which was already registered there worked properly, due to other eac3to bugs at that time.

"This TrueHD track contains only 16 bit of information.
The zero bytes were successfully removed from the raw file."
flac file size is 18,5mb now -.-

shit, it was my own fault. sorry for taking up so much of your time with that :/

Last edited by Thunderbolt8; 5th October 2007 at 12:12.
Thunderbolt8 is offline   Reply With Quote
Old 5th October 2007, 12:09   #1045  |  Link
TheSof
Registered User
 
Join Date: Aug 2007
Posts: 34
Quote:
Originally Posted by madshi View Post
Can you please retry with v1.22? If the problem still exists in that version, I'll do some more checks.
Retried with latest version (1.23) and all is welll again with regard to runtimes, although I will not have the chance to hear the results until later.

True HD file size is 1.57GB

TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
The following tasks are executed now. Please wait...
- remove Dialog Normalization information
- muxing TrueHD track into temp evo file
Decoding TrueHD track to raw. Please wait...
Checking raw data bitdepth. Please wait...
This TrueHD track contains only 16 bit of information.
The zero bytes were successfully removed from the raw file.
Encoding the raw file to FLAC. Please wait...

Done.

FLAC file size is 1.39 GB.

Runtime now matches, being 2:34:19. This is with Superman Returns. When I get a chance to play it I will post the delay info.

Thanks madshi.

EDIT - comparing the file properties of the 1.18 flac and the 1.23 flac, the difference was the sampling rate, 44 vs 48, so you were correct, that was the issue. Thanks for fixing it.

Last edited by TheSof; 5th October 2007 at 12:15.
TheSof is offline   Reply With Quote
Old 5th October 2007, 12:14   #1046  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by Thunderbolt8 View Post
shit, it was my own fault. sorry for taking up so much of your time with that :/
No problem. Glad it's solved now.
madshi is offline   Reply With Quote
Old 5th October 2007, 12:16   #1047  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by TheSof View Post
Runtime now matches, being 2:34:19. This is with Superman Returns. When I get a chance to play it I will post the delay info.
Thanks. Please also post the EvoDemux log of that TrueHD track. That goes to everyone: If you convert your TrueHD files to FLAC (or anything else) with the latest eac3to version, and if you need to apply a manual delay, please post your final delay value and the log from EvoDemux. Collecting this kind of information helps other people (they don't need to figure out the delay themselves) and it might also help finding a common base on how to calculate the delay automatically for a future eac3to version.
madshi is offline   Reply With Quote
Old 5th October 2007, 12:17   #1048  |  Link
TheSof
Registered User
 
Join Date: Aug 2007
Posts: 34
Quick question, where is the best place to add the delay for flac - with eac3to or when muxing the mkv?
TheSof is offline   Reply With Quote
Old 5th October 2007, 12:19   #1049  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by TheSof View Post
Quick question, where is the best place to add the delay for flac - with eac3to or when muxing the mkv?
I don't know if mkvtoolnix can properly delay FLAC files. Can it? If it does, it might be the faster way to handle the delay. However, if you demux and remux the FLAC file, the delay might be gone (I'm not sure). When applying the delay with eac3to it's an everlasting fix/change.
madshi is offline   Reply With Quote
Old 5th October 2007, 12:26   #1050  |  Link
TheSof
Registered User
 
Join Date: Aug 2007
Posts: 34
Quote:
Originally Posted by madshi View Post
I don't know if mkvtoolnix can properly delay FLAC files. Can it? If it does, it might be the faster way to handle the delay. However, if you demux and remux the FLAC file, the delay might be gone (I'm not sure). When applying the delay with eac3to it's an everlasting fix/change.
I'll stick to eac3to then.
TheSof is offline   Reply With Quote
Old 5th October 2007, 12:26   #1051  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,170
ill demux the truehd track again with evodemux for the log file, once that conversion here is done (that bitdepth checking takes up lot of time now, was over before in 1 second :P)

should I post the complete log with all infos from all tracks or only certain parts or only the part when he begins to work with the demuxing?
Thunderbolt8 is offline   Reply With Quote
Old 5th October 2007, 12:38   #1052  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by Thunderbolt8 View Post
ill demux the truehd track again with evodemux for the log file, once that conversion here is done (that bitdepth checking takes up lot of time now, was over before in 1 second :P)

should I post the complete log with all infos from all tracks or only certain parts or only the part when he begins to work with the demuxing?
I don't need the demuxing log. I just need some parts of the information EvoDemux posts when you load the EVO file. These infos should be enough:

Code:
PTM of first video frame = 00000123
VC-1 video stream 0 found!
   First PTS = 00000123
Dolby TrueHD audio stream 0 found!
   First PTS = 00000123
Bitdepth checking takes longer now because it aborts as soon as more than 16bits are found, while it runs through until the end of the raw file if it never finds more than 16bit. The reason for that is that the bitdepth checking already strips the zero bytes in a temporary file so that after checking there doesn't need to be an additional step for removing the zero bytes. So the proper name would be "bitdepth checking & zero byte removal". It's done in one step.
madshi is offline   Reply With Quote
Old 5th October 2007, 13:08   #1053  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,170
I guess in cases we would have to apply offsetpts we should do this then before posting these infos, right?


for TrueHD 5.1 of letters from iwo jima (1st EVO)

Code:
PTM of first video frame = 6736B4B1
VC-1 video stream 0 found!
   First PTS = 2736B4B1  (+35791394ms)
Dolby TrueHD audio stream 1 found!
   First PTS = 2736B4B1  (+35791394ms)

Dolby Digital Plus audio stream 0 found!
   First PTS = 6736B4B1

2h 20mn 37s 322ms = length of truehd -> flac
2h 20mn 37s 472ms = length of dd+ -> ac3
2h 20mn 37s 440ms = length of dd+ -> flac

normal truehd -> flac length seemed to need a little delay, which was apparently frome some scenes. decided again to try the mathematical way and to take the difference between the truehd and eac3 track. chose the length of the eac3 -> flac track, because it might be a little more accurate due to those additional 32ms for ac3 frames. just seemed to make most sense to me to compare both of the flac conversions to each other. delay needed is 118ms then. I cant say that this is 100% exact the same delay now as on the source, but I would guess it might be, one just cant be sure 100% without being able to calculate it. at least it was the most accurate value for me so far, so I decided take this one.

118ms is btw also exact the same value I took as delay for the fear & loathing trueHD track. cant say if this is coincidence, just did (almost) the same here, converted the dd+ track to ac3 (and flac? cant remember any more if I converted the dd+ to both) and compared its length to the truehd -> flac track. the difference I got from there was also 118ms, same as here with letters from iwo jima.

values for fear & loathing TrueHD 5.1

Code:
Opening file FEATURE_1.EVO

PTM of first video frame = 00000D8E
Dolby TrueHD audio stream 0 found!
   First PTS = 00000D8E
edit: on the other hand the delay for "letters..." calculated from the eac3 -> ac3 compared to truehd -> clac track of 150ms then could fit as well. too hard to compare 118ms and 150ms with only a difference of 32ms only with the eyes -.-

Last edited by Thunderbolt8; 5th October 2007 at 13:37.
Thunderbolt8 is offline   Reply With Quote
Old 5th October 2007, 14:08   #1054  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by Thunderbolt8 View Post
I guess in cases we would have to apply offsetpts we should do this then before posting these infos, right?
OffsetPTS only changes the timestamps of the 2nd EVO file and those are not important for our needs. So OffsetPTS doesn't make any difference for audio delay.

Quote:
Originally Posted by Thunderbolt8 View Post
for TrueHD 5.1 of letters from iwo jima (1st EVO)
Code:
PTM of first video frame = 6736B4B1
VC-1 video stream 0 found!
   First PTS = 2736B4B1  (+35791394ms)
Dolby TrueHD audio stream 1 found!
   First PTS = 2736B4B1  (+35791394ms)
Dolby Digital Plus audio stream 0 found!
   First PTS = 6736B4B1
Wow, those are quite crazy!

Quote:
Originally Posted by Thunderbolt8 View Post
118ms is btw also exact the same value I took as delay for the fear & loathing trueHD track.
I've had 200ms with two TrueHD tracks as of yet.
madshi is offline   Reply With Quote
Old 5th October 2007, 14:19   #1055  |  Link
TheSof
Registered User
 
Join Date: Aug 2007
Posts: 34
I'm having some problems getting mpc to play the flac as a dub alongside an mkv to find the delay. It just won't open the flac using madflac or any others. Graphedit plays them fine. Anyone know what I'm doing wrong?
TheSof is offline   Reply With Quote
Old 5th October 2007, 14:25   #1056  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by TheSof View Post
I'm having some problems getting mpc to play the flac as a dub alongside an mkv to find the delay. It just won't open the flac using madflac or any others. Graphedit plays them fine. Anyone know what I'm doing wrong?
You need to tell MPC to load the FLAC file by starting MPC with the "dub" parameter via command line.
madshi is offline   Reply With Quote
Old 5th October 2007, 15:00   #1057  |  Link
TheSof
Registered User
 
Join Date: Aug 2007
Posts: 34
Let me start off by saying that I hate finding delays - I'm terrible at it and it takes me ages.

Having said that, I thought that superman returns stayed insync through out, without any delay. I'm going to try V for Vendetta and Harry Potter next.
TheSof is offline   Reply With Quote
Old 5th October 2007, 15:04   #1058  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by TheSof View Post
Let me start off by saying that I hate finding delays - I'm terrible at it and it takes me ages.
As with everything, you'll improve with some practising...

Quote:
Originally Posted by TheSof View Post
Having said that, I thought that superman returns stayed insync through out, without any delay. I'm going to try V for Vendetta and Harry Potter next.
That's fine.
madshi is offline   Reply With Quote
Old 5th October 2007, 15:11   #1059  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,170
should we also post a log for cases we believe there is no delay needed at all?
Thunderbolt8 is offline   Reply With Quote
Old 5th October 2007, 15:12   #1060  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,126
Quote:
Originally Posted by Thunderbolt8 View Post
should we also post a log for cases we believe there is no delay needed at all?
Well, it might be helpful. At least it won't harm.
madshi is offline   Reply With Quote
Reply

Tags
eac3to

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 21:18.


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