eac3to - audio conversion tool

[Thunderbolt8]

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

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]

Originally Posted by honai

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.

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]

Originally Posted by 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 ?

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

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]

Originally Posted by Thunderbolt8

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]

Originally Posted by Thunderbolt8

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

Originally Posted by Thunderbolt8

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]

Originally Posted by TheSof

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]

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

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]

Originally Posted by 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?

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]

Originally Posted by 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)?

I've not had any problems with delay running out of sync in the middle of a movie yet, if you mean that.