eac3to - audio conversion tool

[Thunderbolt8]

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?

[madshi]

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:

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.

[Thunderbolt8]

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)

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

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 -.-

[madshi]

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.

for TrueHD 5.1 of letters from iwo jima (1st EVO)
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!

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.

[TheSof]

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?

[madshi]

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.

[TheSof]

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.

[madshi]

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... :p

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.

[Thunderbolt8]

should we also post a log for cases we believe there is no delay needed at all?

[madshi]

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.

[Thunderbolt8]

after all its only us who believe(!) we dont need any delay :P

[honai]

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

Personally, I don't think that's such a good idea. For one thing - and I really don't mean to be rude - a great many people just don't know what they're doing. But the biggest problem is that, while the effort may be well-intentioned, specific setups might yield a delay that's only valid for the environment of that specific user.

What I mean is this:
- the user might have a filter in the audio chain that causes a small delay, e.g. for downconverting multi-channel to stereo setups, or applying inherent effects on the sound card (many Creative card exhibit this)
- the user might be using an LCD display with implicit video delay (most overdrive/PVA panels and most panels with 10-bit LUTs exhibit a delay of up to 50ms caused by the display's DSP circuitry)
- if running audio through a receiver that might also introduce another delay

These factors could quickly sum up into the 100ms range, i.e. a/v is perfectly in sync to the user, but only for his specific setup, while the actual a/v sync is off by up to 100ms!

[TheSof]

I still think it's a good idea, even if it's just to know how many need delay and how many don't

We have to assume that the user is already adding a global delay via receiver, soundcard or ffdshow etc. if it's needed in that particular environment.

I also don't think they should be taken as concrete proof, but just as a guideline, perhaps as a starting point.

[madshi]

Personally, I don't think that's such a good idea. For one thing - and I really don't mean to be rude - a great many people just don't know what they're doing. But the biggest problem is that, while the effort may be well-intentioned, specific setups might yield a delay that's only valid for the environment of that specific user.

What I mean is this:
- the user might have a filter in the audio chain that causes a small delay, e.g. for downconverting multi-channel to stereo setups, or applying inherent effects on the sound card (many Creative card exhibit this)
- the user might be using an LCD display with implicit video delay (most overdrive/PVA panels and most panels with 10-bit LUTs exhibit a delay of up to 50ms caused by the display's DSP circuitry)
- if running audio through a receiver that might also introduce another delay

These factors could quickly sum up into the 100ms range, i.e. a/v is perfectly in sync to the user, but only for his specific setup, while the actual a/v sync is off by up to 100ms!
I see what you mean but I think users which need such a setup related delay will hopefully have dialed that in in the receiver. I mean otherwise they'd have to apply a delay to every SD-DVD they rip, too! And to any movie they might download.

[honai]

I see what you mean but I think users which need such a setup related delay will hopefully have dialed that in in the receiver. I mean otherwise they'd have to apply a delay to every SD-DVD they rip, too! And to any movie they might download.

Well, many users have really, really low expectations, and while some may notice that "something" is wrong they couldn't nail it where and what went wrong.

I'm just saying that there are too many factors in the equation to come up with a reliable way of determining the actual delay.

[Thunderbolt8]

could anyone already tell please how blue ray tracks behave with the current eac3to version? was it said somewhere that the LPCM tracks wont suffer from delay when converting to flac or do I have kept something wrong in my mind regarding that aspect?
has anyone already tried converting blueray trueHD tracks to flac, if yes do they also need delay like (most of) those on HDDVDs ?

[madshi]

could anyone already tell please how blue ray tracks behave with the current eac3to version? was it said somewhere that the LPCM tracks wont suffer from delay when converting to flac or do I have kept something wrong in my mind regarding that aspect?
has anyone already tried converting blueray trueHD tracks to flac, if yes do they also need delay like (most of) those on HDDVDs ?
The conversion to FLAC is usually not what is creating any delays. It's the demuxing. If you encode a decoded TrueHD or LPCM track to FLAC or AC3 or DTS shouldn't matter much.

About LPCM tracks: I'm not sure myself. I have converted some LPCM tracks to FLAC, but I don't remember if I had to apply a delay or not. I don't consider it a big problem, so that's probably why I don't remember...

[honai]

On the last few Blu-Rays that I converted - 300, The Prestige, The Lives of Others, Pirates of the Caribbean - no delay was needed.

[Thunderbolt8]

did you try it with both 300 tracks, LPCM and trueHD, or only with the LPCM one? could be interesting to know

[madshi]

did you try it with both 300 tracks, LPCM and trueHD, or only with the LPCM one? could be interesting to know
Just for my interest I compared different tracks from the 300 Blu-Ray disc today. It's an interesting disc because several tracks are available in two different formats:

(1) There's a 16bit LPCM track.
(2) There's a 16bit TrueHD track.
(3) There's a 640kbps AC3 track interweaved with the TrueHD track.
(4) There's a separate 640kbps AC3 track.

I've compared (3) and (4) first. The AC3 track from (3) was extracted by using eac3to. Both AC3 tracks are 100% identical - except the last two AC3 frames, which are different for whatever reason. That's 64ms worth of audio data at the end of the movie. Everything else is bit perfectly the same. So also the delay is the same.

Then I've compared (1) and (2). Here it gets a bit funny. There are the following differences between the two tracks:

- there's 105ms of additional audio data in the beginning of the LPCM track
- there's 98ms of additional audio data at the end of the LPCM track
- at timecode 0:00:35 there's additional 20ms audio data in the LPCM track

Apart from these differences the tracks are bit perfectly identical. That means we have the proof now that TrueHD decoding with eac3to and Nero 7 is bit perfect. However, those 20ms of additional audio data in the LPCM track at timecode 0:00:35 are confusing me. I'm not sure where this is coming from. Maybe there's a TrueHD frame which was not decoded for whatever reason? It's really strange...

[Thunderbolt8]

did you compare the original LPCM and trueHD tracks, or both in their converted to flac versions?
when converting both, the LPCM track and the trueHD track to flac, did you have to apply delay for one or both to fit for a remux to .mkv with 23.9760239 fps? if needed for both, was the delay value needed different from both tracks, apart from that stuff that was different anyway due to different additional audio data at beginning/in between/end, which could somehow result from the demux process or such?

[madshi]

did you compare the original LPCM and trueHD tracks, or both in their converted to flac versions?
I compared the raw audio data (after correct channel remapping).

when converting both, the LPCM track and the trueHD track to flac, did you have to apply delay for one or both to fit for a remux to .mkv with 23.9760239 fps?
I haven't remuxed the video yet, so I can't say. However, since the LPCM track has 105ms more audio data in the beginning, the TrueHD decoded track will need 105ms more delay than the LPCM track. If the LPCM track is in sync without any manual delay, the TrueHD track will need exactly 105ms.

[calinb]

Let me start off by saying that I hate finding delays - I'm terrible at it and it takes me ages. <snip>
As mentioned here, MPC is a good tool for finding the delay values because you can quickly change them "on the fly." I remapped the MPC audio delay increase/decrease keys to a more convenient key pair for this purpose.

First, find the audio delay (+/-) necessary to obtain sync early in the file. Next find the delay required late in the file. If they are the same, it's easy--you only need to remux the file with this delay. If they are different, you must remux the file with this delay "offset" but also "stretch/shrink" the audio or adjust the framerate. I use the mkvmerge audio "stretch by" feature, though the tool tips advises the feature doesn't work with all audio formats. If your format doesn't work with mkvmerge, try using another tool like BeSweet to stretch/shrink the audio in the wav files before encoding. The stretch factor is the difference between the early delay value and the late delay value compared to the timestamp (seek position) time difference between them. For example:

1st sync check (ideally at the start of the file):

0:03:04 requires -200ms audio delay


2nd sync check (ideally, much later in the file):

2:02:04 requires +300ms audio delay


The sync checks are located 119 minutes, 0 seconds apart (7140 sec) so the audio must be stretched by 500ms (300ms - (-200ms) = 0.5 sec) over this period.

Enter -200 delay and 7140.5/7140 stretch values into mkvmerge (the GUI accepts fractions).

Of course, this only works if the audio/video "drift" is constant in the file.

[Thunderbolt8]

I'd rather say try to work on the fps settings and alter them a little from 25 or 23.976 fps instead of stretching the audio, because this alters the quality a little.

[calinb]

I'd rather say try to work on the fps settings and alter them a little from 25 or 23.976 fps instead of stretching the audio, because this alters the quality a little.Yes--for no quality loss, I think a timecodes.txt file could be applied to the video stream in mkvmerge:

# timecode format v1
assume 23.976

Just change the the framerate in the 2nd line above before muxing. A more sophisticated timecodes.txt file could probably be used to correct sync where the A/V drift is not constant.

[Thunderbolt8]

I just tried another way to come close to the delay for trueHD for HDDVD remuxes. I rebuilt the .evo of 'letters from iwo jima' with the video and the trueHD track and opened that rebuilt .evo with mediainfo. the length it gave me is 2h 20mn 37s 479ms, 157ms longer than the demuxed & converted trueHD -> flac track. tried the delay and it looked really very well, maybe the best result so far (well of course I wont see any difference between this and the 7ms different value I got from comparism with the converted ac3 track :P )
there are still some questions for me, though.

1. does the delay/length of that trueHD track remains exactly the same when rebuilding it into .evo (either together with the video track or alone, if theres a difference) as it is when just playing back the whole movie normally via its original files, or could already some changes occur in that rebuilding stage with evodemux?

2. mediainfo is not yet (fully) compatible for those new kind of audio tracks yet, for example it wont give you any info when just trying to open a demuxed trueHD or eac3 track with it. however, when I told it to open that rebuilt video & audio .evo file it gave me for this file with only 1 rebuilt audio stream:

General : blablabla\rebuiltVideoAudio.EVO
Format : MPEG-2PS
Length : 19 GiB for 2h 20mn 37s 479ms

Video #0 : VC-1 at 18 Mbps
Aspect : 1920 x 1080 (1.778)

Audio #0 : at 256 Kbps
Infos : , 44 KHz

Audio #1 : at 128 Kbps
Infos : , 44 KHz

the audio info displayed there is beyond reality, theres of course only the 1 trueHD track in it. but the length seems to be correct, when substracting the converted flac track length from it you get the value of 157ms which seems to be perfect for that movie!
maybe we could test if this works for other movies too, madshi (or others too, of course ;) ), if you could just do the same with the trueHD HDDVD movies you have.
if this should be a method how to find the exact delay for those tracks, you could use these accurate delay values and maybe find out how they originate and a way how they can be calculated and delay applied automatically then ;)


edit: well how to proceed in a similar case for blue rays then? mediainfo doesnt give any length on m2ts files, I also tried to use tsremux (even though I dont know if it will stay 100% original sync after that) to make a remux with video and lpcm audio only, but this new m2ts file didnt have any audio in it afterwards, or at least powerdvd and ffdshow both didnt find any.

[Thunderbolt8]

hm I just tried myself on the terminator blue ray, but I got 3 discontinuity errors while trying to demux the LPCM track (2nd audio track on the blue ray) out of the main m2ts file. I used xport 0.98, tried it both ways, one time without any video demuxing and 2nd together with video demuxing but I got the errors both times (both audio streams also had same length at the end). therefore I cant be sure if the converted LPCM -> flac stream is now 100% in sync with the remuxed video to .mkv. maybe im just imagining a tiny delay now, because I know about the discontinuity errors; if there really was a tiny error then it would be only very very small (I'd say <50ms).

any other idea what I could do to prevent this audio demux error?

[madshi]

hm I just tried myself on the terminator blue ray, but I got 3 discontinuity errors while trying to demux the LPCM track (2nd audio track on the blue ray) out of the main m2ts file. I used xport 0.98, tried it both ways, one time without any video demuxing and 2nd together with video demuxing but I got the errors both times (both audio streams also had same length at the end). therefore I cant be sure if the converted LPCM -> flac stream is now 100% in sync with the remuxed video to .mkv. maybe im just imagining a tiny delay now, because I know about the discontinuity errors; if there really was a tiny error then it would be only very very small (I'd say <50ms).

any other idea what I could do to prevent this audio demux error?
I'm having discontinuity errors with many Blu-Rays. I'm just ignoring them and didn't have any problems with that yet.

[Thunderbolt8]

do you mean you dont have any problems with delay then, as the audio track still syncs perfectly or not 'any problems' regarding that video and audio are still playable (but with some small delay needed then)?

[madshi]

do you mean you dont have any problems with delay then, as the audio track still syncs perfectly or not 'any problems' regarding that video and audio are still playable (but with some small delay needed then)?
I've not had any problems with delay running out of sync in the middle of a movie yet, if you mean that.

[Thunderbolt8]

yes, this and how many blue rays movies with LPCM tracks you've tested already did need some initial delay modification? did they all sync perfectly without any delay needed, despite all those discontinuity errors?

[madshi]

yes, this and how many blue rays movies with LPCM tracks you've tested already did need some initial delay modification? did they all sync perfectly without any delay needed, despite all those discontinuity errors?
I've already answered this question in post 1067.

[Thunderbolt8]

well not exactly this question but a quite similar one. must have forgotten to checkmark it on my big question paper. thanks!

[Rectal Prolapse]

The discontinuity errors on Blu-rays *might* be caused by a bad rip - there have been issues in the past where if you use Windows Explorer interface to decrypt blu-ray files with AnyDVD you may get corrupted files.

Best bet is to re-rip them using AnyDVD's tool directly and not use Windows Explorer at all.

[序列人]

c:\audio\eac3to audiodtshd
.thd audiodtshd.flac -24
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 more than 16 bit of information.
Encoding the raw file to FLAC. Please wait...
지정된 경로를 찾을 수 없습니다.

"flac" reported error code "1". A valid *.raw file was created sucessfully, thou
gh.

Why have i got an error message after I use EAC3 V1.11? Thanks in advanced.

[madshi]

Why have i got an error message after I use EAC3 V1.11? Thanks in advanced.
eac3to v1.11? That's a very old version. Try the latest!

Also: Are there really "?" chars in the eac3to output? Do you have a "Flac" folder in your eac3to folder and is there a "flac.exe" inside?

[DeepBeepMeep]

Great tool!

Is there a way to keep the dial norm when extracting an AC3 soundtrack encapsulated in a Dolby True HD track?

Since I don't plan to reencode the AC3 track I would be quite happy to keep the dial norm in this particular case.

I thought the -keepdialnorm option would work here but I lose the dialnorm anyway.

Thanks for your help

[LJstc]

hey madshi!

Thx for your work!

But i try to convert eac3 track from Mission Imp. 3 to ac3 track and also get the 0 Byte error!

Have Nero and codecs correctly installed!

Can you tell me which chain i can use in graph edit to test if it works there?

Which decoders and muxers i need to connect in graph edit?

thx!

[madshi]

I thought the -keepdialnorm option would work here but I lose the dialnorm anyway.
I think there's a bug in the eac3to output text. I think it does say that it removes dialnorm even though you used the "-keepdialnorm" switch, but it doesn't really remove dialnorm. Please try running the extracted AC3 file through eac3to again. If dialnorm is still in there, eac3to will say so.

Another thing to note is that Sony doesn't use dialnorm to begin with. So if it's a Sony Blu-Ray you're talking about, dialnorm was never there.

[madshi]

hey madshi!

Thx for your work!

But i try to convert eac3 track from Mission Imp. 3 to ac3 track and also get the 0 Byte error!

Have Nero and codecs correctly installed!

Can you tell me which chain i can use in graph edit to test if it works there?

Which decoders and muxers i need to connect in graph edit?
You need to rename GraphEdit.exe to Recode.exe. Then you can use the Nero Splitter (or something like that) and the Nero Audio Decoder 2.

Please note that the usual cause of the "0 byte" problem is that you didn't properly buy/license the HD DVD plugin.

[LJstc]

Thank you for your fast answer!

but i registered the HDDVD plugin with the Nero registrator!

i pressed the ADD button in Nero registrator and filled in my HDDVD Plugin serial! Under expire tab stands NONE at HDDVD_TEST feature.


and in graphedit i do have all filters Nero Filesource/Splitter, Nero Audio Decoder 2 properly installed.

i connected Nero File Source/Splitter ---> Nero Audio Decoder2 ---> Dump (test.ac3)

my source file is a demuxed DD+ file with EVODEMUX can that be a problem? because i dont know exactly the ending of the file? EAC3to writes me in dos prompt its a E-AC3 file! so the right extension is EAC3 right? or DDP ?

Recode.exe an setting up the graph as above dont work too i get 0 byte file.

maybe you can tell me some hints with this informations?

[madshi]

but i registered the HDDVD plugin with the Nero registrator!

i pressed the ADD button in Nero registrator and filled in my HDDVD Plugin serial! Under expire tab stands NONE at HDDVD_TEST feature.
Did you correctly buy the plugin?

[LJstc]

Lets say i got a working serial!

Now and its registered correctly in the Nero Register Tab

There Stands "Nero BlueRay/HD-DVD Video plugin" Serial Number and then Expiration NONE

I know i will buy i license this is first only for testing if it works!

[LJstc]

Hey! thanks!

It works now!

Plugin wasnt correctly registered!


Thx for hint!

[TheSof]

Probably answered somewhere before but I couldn't find it.

Superman Returns 1.57GB 16bit THD > FLAC, 16bit 1.39 GB.

V 4 Vendetta 1.27GB 16bitTHD > FLAC, 16bit 1GB

Harry Potter 1.64GB 16bit THD > FLAC 24bit 1.4GB

So I guess I'm asking why some 16bit THD files come out as 16bit FLAC, but others at 24bit when clearly they are really 16bit from looking at the file size?

[madshi]

Probably answered somewhere before but I couldn't find it.

Superman Returns 1.57GB 16bit THD > FLAC, 16bit 1.39 GB.

V 4 Vendetta 1.27GB 16bitTHD > FLAC, 16bit 1GB

Harry Potter 1.64GB 16bit THD > FLAC 24bit 1.4GB

So I guess I'm asking why some 16bit THD files come out as 16bit FLAC, but others at 24bit when clearly they are really 16bit from looking at the file size?
I've really no idea. Maybe the Harry Potter THD file is corrupt? Please try reripping the HD DVD with the latest version of DumpHD and then demux again with the latest version of EvoDemux. Does that fix the problem?

[TheSof]

I've really no idea. Maybe the Harry Potter THD file is corrupt? Please try reripping the HD DVD with the latest version of DumpHD and then demux again with the latest version of EvoDemux. Does that fix the problem?

That could be the reason, but I'm using the latest EvoDemux, and the evo, mkv and flac plays perfect. Ripping the disc again could be a problem as I have sold it on, and it was tough getting my hands on it as it is hard to source.

Indeed, apart from the fact that the flac is 24bit, the file size and runtime are fine. Strange.

[OVEBILL]

Here is some link for XXXXXXXXXXXXXXXXXXXXXXXXXX

[madshi]

That could be the reason, but I'm using the latest EvoDemux, and the evo, mkv and flac plays perfect. Ripping the disc again could be a problem as I have sold it on, and it was tough getting my hands on it as it is hard to source.

Indeed, apart from the fact that the flac is 24bit, the file size and runtime are fine. Strange.
Well, you could try creating a small test sample (10MB). It you can reproduce the problem with that small test sample, you can send it to me. Maybe I can find out the reason why it behaves strange.

[humax]

Hello
I have a problem mith eac3to.

I always geht this message :

http://img159.imageshack.us/img159/6666/soundxq4.th.jpg (http://img159.imageshack.us/my.php?image=soundxq4.jpg)

Is the Gui wrong an i shall use the .exe command file ??
Sonic is installed .
Whats wrong ?

Thx for Help