eac3to - audio conversion tool

[Threedcoder]

I have a movie (the second one in less than a week now) that has the audio lagging behind the video. Prior to this movie, I had only seen this twice before -- on one Bluray and on one HD-DVD.

When the audio lags behind the video, it can be corrected one of two ways:

1. Either padding the video by put blank frames at the start or...
2. Chop some frames off the start of the audio track

In the HD-DVD case, EVODemux actually got it right and was able to display the correct audio advance that would be required in milliseconds to correct the situation.

In both Bluray cases, neither eac3to or tsMuxeR have gotten it right. In fact neither even indicate any kind of delay or advance.

Out of curiosity, how can you get eac3to to display the delay/advance for audio tracks found in a .m2ts file? Is there a command line flag that I'm missing?

Any help on querying for an audio track's delay or advance would be greatly appreciated at this point. At least that way I can manually feed that delay or advance to eac3to when converting the track to a .wav in preparation for splitting it out to 6 mono wavs.

[drmpeg]

Originally Posted by Thunderbolt8

is the number of discarded frames the 'x frames before the first I-frame' number? I already tried to multiply X with 32 and then add the rest ms to that and compare the result with the value eac3to displays, but it wasnt the same. did I do something wrong or how else can I get the same result?

No, that's the number of video frames discarded before the first sequence header. xport doesn't report how much audio is being discarded.

You can use the -a option to figure it out manually. For example:

C:\xfer>xport -a "04-13_15-19-09_PREMIERE HD (eng)_Firewall.ts" 129 1 3
xport Transport Stream Demuxer 1.01a
program = 129, video channel = 1, audio channel = 3
Program Number = 0 (0x0000), Program Map PID = 16 (0x0010)
Program Number = 129 (0x0081), Program Map PID = 98 (0x0062)
Program Number = 130 (0x0082), Program Map PID = 99 (0x0063)
Program Number = 131 (0x0083), Program Map PID = 100 (0x0064)
Program Number = 132 (0x0084), Program Map PID = 101 (0x0065)
program descriptor = 0x09, 0x04, 0x18, 0x01, 0xf6, 0xba
program descriptor = 0x09, 0x04, 0x18, 0x31, 0xfa, 0xba
program descriptor = 0x09, 0x04, 0x18, 0x30, 0xf9, 0xba
ES descriptor for stream type 0x06 = 0x52, 0x01, 0x0a
ES descriptor for stream type 0x06 = 0x56, 0x05, 0x64, 0x65, 0x75, 0x09, 0x00
Video PID =  767 <0x02ff>, type = 0x1b
ES descriptor for stream type 0x1b = 0x52, 0x01, 0x09
ES descriptor for stream type 0x06 = 0x6a, 0x05, 0xf0, 0x0a, 0x08, 0x00, 0x00
ES descriptor for stream type 0x06 = 0x52, 0x01, 0x07
ES descriptor for stream type 0x06 = 0x0a, 0x04, 0x64, 0x65, 0x75, 0x01
Audio PID =  772 <0x0304>, type = 0x06
ES descriptor for stream type 0x06 = 0x0a, 0x04, 0x65, 0x6e, 0x67, 0x01
ES descriptor for stream type 0x06 = 0x6a, 0x05, 0xf0, 0x0a, 0x08, 0x00, 0x00
ES descriptor for stream type 0x06 = 0x52, 0x01, 0x08
Audio PTS = -324288430, -324288430    <----------- first audio frame
Audio PTS = -324285550, 2880
Audio Bitrate = 448000, Audio Sampling Rate = 48000
Audio Mode = 2/0, bsid = 8, bsmod = 0
Audio PTS = -324282670, 2880
Audio PTS = -324279790, 2880
Audio PTS = -324276910, 2880
Audio PTS = -324274030, 2880
Audio PTS = -324271150, 2880
Audio PTS = -324268270, 2880
Audio PTS = -324265390, 2880
Audio PTS = -324262510, 2880
Audio PTS = -324259630, 2880
Audio PTS = -324256750, 2880
Audio PTS = -324253870, 2880
Audio PTS = -324250990, 2880
Audio PTS = -324248110, 2880
Audio PTS = -324245230, 2880
Audio PTS = -324242350, 2880
Audio PTS = -324239470, 2880
Audio PTS = -324236590, 2880
Audio PTS = -324233710, 2880
Audio PTS = -324230830, 2880
Audio PTS = -324227950, 2880
Audio PTS = -324225070, 2880
Audio PTS = -324222190, 2880
Audio PTS = -324219310, 2880
Audio PTS = -324216430, 2880
Audio PTS = -324213550, 2880
Audio PTS = -324210670, 2880
Audio PTS = -324207790, 2880
Audio PTS = -324204910, 2880
Audio PTS = -324202030, 2880
Audio PTS = -324199150, 2880
Audio PTS = -324196270, 2880
Audio PTS = -324193390, 2880
Audio PTS = -324190510, 2880
Audio PTS = -324187630, 2880
Audio PTS = -324184750, 2880
Audio PTS = -324181870, 2880
Audio PTS = -324178990, 2880
Audio PTS = -324176110, 2880
Audio PTS = -324173230, 2880
Audio PTS = -324170350, 2880
Audio PTS = -324167470, 2880
Audio PTS = -324164590, 2880
Audio PTS = -324161710, 2880
Audio PTS = -324158830, 2880
Audio PTS = -324155950, 2880
Audio PTS = -324153070, 2880
Audio PTS = -324150190, 2880
Audio PTS = -324147310, 2880
Audio PTS = -324144430, 2880
Audio PTS = -324141550, 2880
Audio PTS = -324138670, 2880
Audio PTS = -324135790, 2880
38 frames before first I-frame
Main Profile
Level = 4.0
Audio PTS = -324132910, 2880
Audio PTS = -324130030, 2880
Audio PTS = -324127150, 2880
First Video PTS = 0xecaf3582
Audio PTS = -324124270, 2880
Audio PTS = -324121390, 2880
Audio PTS = -324118510, 2880
Audio PTS = -324115630, 2880
Audio PTS = -324112750, 2880
Audio PTS = -324109870, 2880
Audio PTS = -324106990, 2880
Audio PTS = -324104110, 2880
Audio PTS = -324101230, 2880
Audio PTS = -324098350, 2880
Audio PTS = -324095470, 2880
Audio PTS = -324092590, 2880
Audio PTS = -324089710, 2880
Audio PTS = -324086830, 2880
Audio PTS = -324083950, 2880
Audio PTS = -324081070, 2880
Audio PTS = -324078190, 2880
Audio PTS = -324075310, 2880
Audio PTS = -324072430, 2880
Audio PTS = -324069550, 2880
Audio PTS = -324066670, 2880
Audio PTS = -324063790, 2880    <------- (-324063790) = 0xecaf2dd2
Audio PTS = -324060910, 2880
First Audio PTS = 0xecaf2dd2, -1968
Audio PTS = -324058030, 2880
Audio PTS = -324055150, 2880
Audio PTS = -324052270, 2880
Audio PTS = -324049390, 2880

It chopped off 78 AC3 frames. (-324063790) - (-324288430) = 224680

224680 / 2880 = 78

Ron

[BLKMGK]

Originally Posted by inmetzi

Sorry but what are this forum for? How should madshi really make a good work without response about errors. With your comments you can´t really help madshi and other users. Give constructive help and no silly sayings. I´m using eac3to really many months.

So what you are telling me is that you didn't even BOTHER to look and see what the pastebin.com is? Pastebin is a site DESIGNED to allow the pasting of long log files. The interface is designed to allow for easy review and they can be expired after a period of time instead of taking up space here FOREVER. From the top of the page you didn't read "pastebin - collaborative debugging tool"

[Kurtnoise]

@madshi : a small request...could you add the eac3to version # in your matroska writing app string ?

[azad]

Would it be possible to add a new switch for optional activating/deactivating of the audio delay handling of eac3to?

Since version 2.40 eac3to seems to find an audio delay for nearly every bd where the versions before 2.40 didn't find an audio delay.
I know that madshi fixed some problem with the audio delay detection for ts/m2ts files, but also xport reports that there are no audioframes before the first video pts, so I don't want eac3to to cut or add some audioframes if not necessary.

[madshi]

Originally Posted by Chumbo

The log option doesn't seem to be working.

Oooops. Will be fixed in v2.41.

Originally Posted by saint-francis

I just used eac3to to remux Stardust to .mkv and when I loaded it into MeGUI's avisynth script creator it told me that the frame rate was 29.97000002997. When I list the tracks in eac3to it tells me that it's 1080p 24/1.001. Up until now MeGUI has been faultless in this respect. So where is the problem? Was the timestamp written improperly by eac3to?

Stardust is h264 while most other HD DVDs are VC-1. Maybe that's the difference? eac3to should do everything correctly. You can double check by using "mkvinfo movie.mkv".

Originally Posted by mikeathome

Noticed the gap reporting video length? Wrong, clip is 02:02mins. Result plays to fast.

Can I have a sample, please?

Originally Posted by inmetzi

Hi folks, I´m a newbie in this forum, but reading all posts the last weeks. Now I have a problem with the last version (2.40). 2.39 is ok. Because the bugreport can´t be sent emails from the other machine, I will copy it in there

This bug should be fixed in v2.41.

No biggie, but next time when you post a bug report to the forum, could you please put it in between "[ code ]" and "[ /code ]" (without the spaces)? That will make it better readable and it will also consume much less space. Thanks!

Originally Posted by Kurtnoise13

@madshi : a small request...could you add the eac3to version # in your matroska writing app string ?

The Haali Matroska Muxer DirectShow filter puts the string there, I've no direct control over it.

Originally Posted by Threedcoder

I have a movie (the second one in less than a week now) that has the audio lagging behind the video. Prior to this movie, I had only seen this twice before -- on one Bluray and on one HD-DVD.

When the audio lags behind the video, it can be corrected one of two ways:

1. Either padding the video by put blank frames at the start or...
2. Chop some frames off the start of the audio track

In the HD-DVD case, EVODemux actually got it right and was able to display the correct audio advance that would be required in milliseconds to correct the situation.

In both Bluray cases, neither eac3to or tsMuxeR have gotten it right. In fact neither even indicate any kind of delay or advance.

Can I have a sample, please? The first 50MB should be enough. Thanks!

Originally Posted by Threedcoder

Out of curiosity, how can you get eac3to to display the delay/advance for audio tracks found in a .m2ts file? Is there a command line flag that I'm missing?

Just type "eac3to whatever.m2ts" or "eac3to whatever.evo" and you'll see the audio delays listed for all audio tracks (if no delay is needed, it is not shown).

Originally Posted by Threedcoder

Any help on querying for an audio track's delay or advance would be greatly appreciated at this point. At least that way I can manually feed that delay or advance to eac3to when converting the track to a .wav in preparation for splitting it out to 6 mono wavs.

Which tool are you using to demux the audio tracks? If you use eac3to, the needed audio delays should be applied automatically.

Originally Posted by azad

Would it be possible to add a new switch for optional activating/deactivating of the audio delay handling of eac3to?

It's already there. E.g. if eac3to shows "+100ms" you can disable audio delay handling by adding "-100ms" to the command line.

Originally Posted by Thunderbolt8

when I try to de or remux a mpeg2 .ts cap then I get different values for the audio delay from xport and eac3to, in this case here (-661 ticks = ~-7ms from xport and -581ms from eac3to). which one is correct here?

As drmpeg already hinted, eac3to and xport may use slightly different ways to print out the delay. eac3to cumulates every bit of audio data it chops off into the displayed audio delay. IIRC xport shows the timestamp differences as the audio delay, but chops off some additional frames sometimes. What you should probably do is let both xport and eac3to demux that audio track and check whether the resulting files have a different delay. You can check that either in a hexeditor. Or you could also decode both tracks to WAV and compare them in a WAV editor. Finally, if you find that they are really different, it would be interesting to find out which is better... Probably they will be identical, though, or at least very near. eac3to uses totally different code to calculate the delay, so maybe there really is a difference somewhere. I did double check eac3to's delay logic with some test streams which had very big delays in them and the final result was spot on. So I think eac3to calculates the delay correctly.

[madshi]

eac3to v2.41 released

http://madshi.net/eac3to.zip

* added full MP2 (MPEG2 audio) support including decoding + bitstream delay
* added TS/M2TS runtime detection
* improved VOB/EVO runtime detection
* added TrueHD gap/overlap detection
* audio gap/overlap detection logic rewritten (not complete yet)
* fixed: log file option didn't work correctly
* fixed: some DTS tracks in PAL TS broadcasts weren't detected correctly
* fixed: some E-AC3 tracks in PAL TS broadcasts weren't detected correctly

[nautilus7]

Thanks madshi.

MP2 decoding is done through libav?

[madshi]

Originally Posted by nautilus7

MP2 decoding is done through libav?

See 1st post. Yes, default decoder is libav. But Sonic and Nero both also work.

[Thunderbolt8]

Originally Posted by madshi

I did double check eac3to's delay logic with some test streams which had very big delays in them and the final result was spot on. So I think eac3to calculates the delay correctly.

yes, I believe that it definately calculates and treats it correctly, but I was hinting at what is displayed, since you once said in a post that this displayed information could be sometimes a bit different from the real value which is applied.

thanks for the new version btw. of course

[rickardk]

Thanks for latest development!

[rica]

Congrats to you madshi

This time i directly demux my problematic Terminator3 rip;
it worked; thanks again.

eac3to v2.41
command line: "C:\Users\rica\Desktop\Eac3to\eac3to.exe" "E:\TERMINATOR_3_HDDVD\HVDVD_TS\PEVOB_1.EVO" "E:\TERMINATOR_3_HDDVD\HVDVD_TS\PEVOB_1.ac3"
------------------------------------------------------------------------------
EVO, 2 video tracks, 7 audio tracks, 4 subtitle tracks, 0:54:56
1: VC-1, 1080p24 /1.001 (16:9)
2: VC-1, 480p30 /1.001 (3:2)
3: E-AC3, English, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
4: E-AC3, French, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
5: E-AC3, Spanish, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
6: E-AC3, English, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
"Director Commentary"
7: E-AC3, English, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
"Crew Commentary"
8: E-AC3, English, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
"Cast and Crew Commentary"
9: E-AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
10: Subtitle, English
11: Subtitle, English, "SDH"
12: Subtitle, French
13: Subtitle, Spanish
Track 3 is used for destination file "PEVOB_1.ac3".
Extracting audio track number 3...
Removing dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
Disabling DRC for Nero (E-)AC3 decoding...
DirectShow reports 5.1 channels, 24 bits, 48khz
Encoding AC3...
Creating file "E:\TERMINATOR_3_HDDVD\HVDVD_TS\PEVOB_1.ac3"...
eac3to processing took 3 minutes, 35 seconds.
Done.

[Thunderbolt8]

got a h264 .ts cap (with 3 audio glitches according to mpeg2repair), for which eac3to 2.41 now says that its not a valid (e)ac3 stream and therefore the audio stream is not displayed and selectable at all for muxing. is this supposed to be correct?

eac3to v2.41
command line: eac3to G:\breakfast.ts G:\breakfast.mkv
------------------------------------------------------------------------------
This doesn't seem to be a valid (E-)AC3 stream.
TS, 1 video track, 1:50:03
1: h264/AVC, 1080i50 (16:9)
Extracting primary video track...
Muxing video to Matroska...
This TS/M2TS file seems to be damaged (discontinuity).
Aborted at file position 3599433728.

[Denner]

Hey...

Thanks for anoter great update

Any news on when joining m2ts files will be incorporated in to eac3to ?

[madshi]

Originally Posted by Thunderbolt8

p.s. any chance to see that eac3to works on streams which switch from interlaced / progressive? I can virtually not use eac3to for any single mpeg2 1080i cap because of that :/

That is high on my priority list - but still after completion of the Blu-Ray support.

Originally Posted by Thunderbolt8

got a h264 .ts cap (with 3 audio glitches according to mpeg2repair), for which eac3to 2.41 now says that its not a valid (e)ac3 stream and therefore the audio stream is not displayed and selectable at all for muxing. is this supposed to be correct?

This doesn't seem to be a valid (E-)AC3 stream.
This TS/M2TS file seems to be damaged (discontinuity).
Aborted at file position 3599433728.

Where are the glitches according to mpeg2repair? Right in the beginning of the movie? If so, that would explain why eac3to doesn't like/list the audio track. That may not be nice (and will someday be improved), but currently this is "expected behaviour".

BTW, that file also seems to have a discontinuity at about 3.5GB. You can skip over it by using the "-ignorediscon" switch. But you'll probably get image corruption at that place.

Originally Posted by Denner

Any news on when joining m2ts files will be incorporated in to eac3to ?

Shouldn't be too far away now. Much of the preparation work required for that feature is already mostly done (e.g. the rewritten audio gap/overlap logic in v2.41). I expect that seamless branching titles with multiple parts will probably need 2 passes. The 2nd pass would then remove overlapping audio frames (and fill up audio gaps, if necessary) to make sure that audio stays in sync throughout the whole movie.

[azad]

Originally Posted by madshi

It's already there. E.g. if eac3to shows "+100ms" you can disable audio delay handling by adding "-100ms" to the command line.

Thanks!

@madshi
Just for my understanding I've another question regarding the audio delays in m2ts files - How is it possible that eac3to reports a negative audio delay when xport reports no audioframes before the first video pts? Isn't at least one audioframe required to calculate a possible negative audio delay?
Thanks in advance!

[madshi]

Originally Posted by azad

How is it possible that eac3to reports a negative audio delay when xport reports no audioframes before the first video pts?

There's a difference between the first video pts and the first "i" frame pts. I'm not sure if that is where the difference is coming from. I don't have the xport source code in my head right now.

[umaximus]

Originally Posted by madshi

Shouldn't be too far away now. Much of the preparation work required for that feature is already mostly done (e.g. the rewritten audio gap/overlap logic in v2.41). I expect that seamless branching titles with multiple parts will probably need 2 passes. The 2nd pass would then remove overlapping audio frames (and fill up audio gaps, if necessary) to make sure that audio stays in sync throughout the whole movie.

cant wait! it sounds that will handle already joined m2ts too, as long as eac3to pass the mux (on most of joined titles eac3to reports not valid PES packets)?

[azad]

Originally Posted by madshi

There's a difference between the first video pts and the first "i" frame pts. I'm not sure if that is where the difference is coming from. I don't have the xport source code in my head right now.

I guess thats it, somewhere in this forum I read that xport uses the first "I" frame for chopping the audioframes before.

[madshi]

Originally Posted by umaximus

cant wait! it sounds that will handle already joined m2ts too, as long as eac3to pass the mux (on most of joined titles eac3to reports not valid PES packets)?

I think already joined files will not work too well because eac3to will not know where exactly the join points are. So eac3to will not be able to do special processing on the timestamps on the join points. The best result will definitely be achieved by feeding the separate m2ts parts to eac3to and letting eac3to do all the work.

Basically I'm planning to handle the joining in such a way that the video at the join points is seen as a constant stream of frames without any gaps/overlaps (if necessary I'll change the timecodes accordingly). The audio timestamps will then decide about where eac3to will add/remove audio frames. If the parts were already joined before eac3to gets active, eac3to cannot do anything about the video timecodes. That means there may be a tiny amount of motion judder at the join points - depending on how well TsRemux is working...