eac3to - audio conversion tool

[tebasuna51]

So, is there anything i can do? Can i fix the header?

Like Madshi say you can use a hex editor (WinHex or the free HxD (http://www.mh-nexus.de)) to try to correct them.

With your sample you can correct the problem if you:

1) Open test.eac3 in HxD and go to Offset(d) 2840576 (or Offset(h) 2B5800). The offset is (Frame reported by DelayCut -1) * FrameSize = (2775 - 1) * 1024 = 2840576

2) Replace the values in the sample: DB 00 0A D0
by the correct values: 0B 77 01 FF
and save the file.

3) Now you can check test.eac3 with DelayCut with no errors, then the CRC are ok.

[honai]

@madshi

I've extracted the PCM from POTC3 with xport (-h) and used the -bluray switch to convert it to WAVs. The channel mapping in the end is correct. But shouldn't it be messed up now according to your explanation?

[menlvd]

i try to reencode ddp track with -libav option and get bad sound
but when reencode with nero have a normal sound
I'll upload short cut off resulting file

2 minutes (http://rapidshare.com/files/71931453/pay-libav_bad.ac3)

[MichalHabart]

Good question. I should have explained it.

eac3to doesn't really know (and has no way to find out) in which order the channels are, if you feed it with a RAW or PCM file. The previous eac3to version made it simple: RAW input files were not supported. Only PCM files (files with the extension "pcm") were supported. Basically eac3to interpreted any PCM file input as being Blu-Ray and thus automatically remapped the channels accordingly.

But now the new eac3to version supports both PCM and RAW files (which are really one and the same). It's impossible to know whether the file came from Blu-Ray or not. So it's also impossible to know whether the channels need to be remapped or not. eac3to v2.x now does an educated guess: PCM tracks from Blu-Ray are usually big endian. RAW tracks decoded from any DirectShow (or other) decoder are usually little endian. So eac3to v2.x handles big endian RAW/PCM files as coming from Blu-Ray and little endian RAW/PCM files as not coming from Blu-Ray. As a result channels are remapped according to Blu-Ray specs when the source file is big endian. And channels are NOT remapped at all when the source file is little endian. If the channels are remapped eac3to v2.x sais so (something like "this is probably a Blu-Ray PCM file, so I'll remap the channels").

If you demux Blu-Ray (L)PCM tracks with either xport or TsRemux the demuxed files will be big endian. In this case you don't need to tell eac3to anything. Just call it as usual with "eac3to source.pcm dest.whatever" and the channels will be automatically remapped correctly. However, if you demux Blu-Ray (L)PCM tracks by using GraphEdit -> SomeSplitter -> Dump, the resulting file will be little endian. As a result eac3to will think that this file is not coming from Blu-Ray. In this case you can use the reintroduced switch "-blu-ray" to force eac3to to remap the channels. But you need to be cautious: The DirectShow splitter might already have remapped the channels - or not.

Short version: If you use xport or TsRemux for demuxing Blu-Ray (L)PCM tracks, you don't need the "-blu-ray" switch. eac3to v2.x will still automatically remap the channels correctly for you.

Thank you for very good explanation.

[nautilus7]

Well, you could check the frame size (in bytes) in delaycut. Then with a hex editor you can search for the frame where the first two bytes of the frame are not correct and manually correct them. Of course this only works if the "garbage" in your track is exactly one frame long. If it's real added garbage, it'd be better to skip that data. If it's not real garbage, but just a corrupted frame then it might be better to silence the frame.I believe the garbage is 1 frame long only, 2 frames with problem. Silence doesn't work and the frames are always skipped as you told me before because they are not valid.

Like Madshi say you can use a hex editor (WinHex or the free HxD (http://www.mh-nexus.de)) to try to correct them.

With your sample you can correct the problem if you:

1) Open test.eac3 in HxD and go to Offset(d) 2840576 (or Offset(h) 2B5800). The offset is (Frame reported by DelayCut -1) * FrameSize = (2775 - 1) * 1024 = 2840576

2) Replace the values in the sample: DB 00 0A D0
by the correct values: 0B 77 01 FF
and save the file.

3) Now you can check test.eac3 with DelayCut with no errors, then the CRC are ok.

The correct value for the frame header is the same for every frame? I mean do i put the same value for the other bad frame in the track?

I 'll try it and report back. Hope it works!

EDIT: I corrected the 2 frames and now eac3to seems to accept the track properly! Thank you both very much!

[madshi]

I've extracted the PCM from POTC3 with xport (-h) and used the -bluray switch to convert it to WAVs. The channel mapping in the end is correct. But shouldn't it be messed up now according to your explanation?
No, why? "xport"ed PCM tracks are big endian. So eac3to enabled the "-blu-ray" switch automatically. You manually enabled that switch, too, which had no effect, since it was already automatically enabled by eac3to.

[madshi]

i try to reencode ddp track with -libav option and get bad sound
I'm not in a position to fix the sound. Have you read what I wrote in the eac3to v2.05 release notes?

The libav E-AC3 decoder is not useable yet IMHO. It sometimes gives out distorted sound for me. I've still enabled it so that you can play with it, if you like.

[honai]

No, why?

It seemed from your first explanation that the -blu-ray switch also forcefully remaps channels (in which case it'd have messed up the order because it was correct to start with). Obviously that's not the case.

[madshi]

It seemed from your first explanation that the -blu-ray switch also forcefully remaps channels (in which case it'd have messed up the order because it was correct to start with). Obviously that's not the case.
No, the order was not correct to start with. It needed to be corrected. But of course eac3to is not that stupid that it executes the Blu-Ray channel remapping twice on the same data... :)

[honai]

Hmm. How exactly does eac3to determine the channel order in the source PCM? By some heuristic on the presumed LFE channel? Or is -blu-ray always enabled for all .pcm content? This is really confusing.

[madshi]

Hmm. How exactly does eac3to determine the channel order in the source PCM? By some heuristic on the presumed LFE channel? Or is -blu-ray always enabled for all .pcm content? This is really confusing.
Please read my very long explanation I posted as a reply to MichalHabart's question. It explains what happens fairly extensively. Basically "-blu-ray" is automatically enabled for big endian raw/pcm files.

[honai]

I did that, and from what I've read so far it seems that eac3to will remap channels if the source is big-endian, regardless of the actual channel order. Which means that if the source PCM happens to be big-endian but already has the correct channel order, eac3to will mess it up implicitly. I don't think that's desirable behavior. The endianness and channel ordering should be decoupled.

This is all assuming that you still want to develop eac3to as a general audio tool, in which case the above educated guesses about the format of the source could very well be wrong for a great number of audio sources.

Concrete suggestion: Change the "-blu-ray" option into "-xport" (or something to that effect) to indicate that the source is from xport and is big-endian *and* has Blu-ray channel order.

[madshi]

I did that, and from what I've read so far it seems that eac3to will remap channels if the source is big-endian, regardless of the actual channel order. Which means that if the source PCM happens to be big-endian but already has the correct channel order, eac3to will mess it up implicitly. I don't think that's desirable behavior. The endianness and channel ordering should be decoupled.

This is all assuming that you still want to develop eac3to as a general audio tool, in which case the above educated guesses about the format of the source could very well be wrong for a great number of audio sources.

Concrete suggestion: Change the "-blu-ray" option into "-xport" (or something to that effect) to indicate that the source is from xport and is big-endian *and* has Blu-ray channel order.
Well, I respect your point of view, but mine happens to differ. eac3to was written mainly as a tool for HD DVD and Blu-Ray tracks. Ok, it does more than that right now, but the primary focus is still to make converting HD DVD and Blu-Ray tracks as easy as possible. I don't want people to remember having to add a "-blu-ray" or "-xport" switch everytime they convert a Blu-Ray (L)PCM track.

Please name a few multichannel sources which are big endian and do *not* have the Blu-Ray channel ordering. Are there any? I'm not aware of any such sources. Because of that I don't think there's any danger in automatically activating the "-blu-ray" switch for big endian PCM files. You can try to convince me otherwise, but you'll need good arguments... :) E.g. it would help if you could say where a big endian PCM track with WAV channel order could come from.

Of course you can force eac3to to not remap channels by overwriting the channel mapping matrix (e.g. "eac3to source.pcm dest.whatever -0,1,2,3,4,5").

[Thunderbolt8]

According to the real data inside.
ok, is this now 100% sure? or could it be because maybe there wasnt any data for the other 2 channels in that sample I gave = would it help if I provided another sample?

[madshi]

ok, is this now 100% sure? or could it be because maybe there wasnt any data for the other 2 channels in that sample I gave = would it help if I provided another sample?
It's 100% sure, as far as I can say.

Besides, I've searched and didn't find a single HD DVD or Blu-Ray disc with a 7.1 TrueHD. It seems such a disc doesn't exist yet. I also didn't find any disc with a 7.1 E-AC3 track.

[Thunderbolt8]

good, then trueHd decoding seems to be complete :D

[Snowknight26]

So I tried converting the Poseidon TrueHD track (24bit) to DTS and FLAC, but I noticed different lengths. I then compared it to my previous conversions, and the DTS length was different yet again.

eac3to v2.05:
DTS, 5.1 channels, 1:38:44, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

eac3to v1.23:
DTS, 5.1 channels, 1:40:18, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

How do I know which one is the proper one (if any), and why do the DTS transcodes have varying length?

Edit:
I also compared a different DD+ track to various encodes. Source is "E-AC3, 5.1 channels, 1:47:35, 1536kbit/s, 48khz, dialnorm: -27dB" according to eac3to v2.05. Then just for the heck of it, I converted that to AC3 using v2.05.

eac3to v2.05:
DTS, 5.1 channels, 1:48:09, 24 bits, 1536kbit/s, 48khz
AC3, 5.1 channels, 1:47:35, 640kbit/s, 48khz

eac3to v1.23:
DTS, 5.1 channels, 1:49:52, 24 bits, 1536kbit/s, 48khz

:\

[Thunderbolt8]

a question regarding that trueHD syncing, could it be possible that the track (flac from truehd) is always in sync now, even if evodemux states a delay for it regarding different first pts?
im trying to remux batman begins and according to evodemux the track should need -200ms of delay. but frankly said some scenes are like this and some (actually most) fit better without that -200. thats why Im asking if with that sync fix something like this could have happened as (unintended?) side effect. or could it possibly be that the delay is different for the 1st and 2nd evo in this special case? some situations definately look a bit differently regarding sync compared to playback of the disc with powerdvd.

Opening file PEVOB_1.EVO
Reading...
File size: 11205 Mbytes.
VOB number 4 contains 2 video , 5 audio and 4 subpicture streams.
PTM of first video frame = 00000D61
PTM of last video frame = 19B28220
Duration = 1:19:50.286
VC-1 video stream 0 found!
First PTS = 00000D61
Dolby TrueHD audio stream 1 found!
First PTS = 000053C3 (+200ms)

Opening file PEVOB_2.EVO
Reading...
File size: 7732 Mbytes.
VOB number 5 contains 2 video , 5 audio and 4 subpicture streams.
PTM of first video frame = 19B28220
PTM of last video frame = 2D139A61
Duration = 1:00:12.559
VC-1 video stream 0 found!
First PTS = 19B28220 (+4790285ms)
Dolby TrueHD audio stream 1 found!
First PTS = 19B2659A (+4790204ms)

ive just noticed that compared to powerdvd the playtime is 8 seconds longer, but theres no other delay specific problem other than the one I related to (meaning the delay is not off by 8 seconds). still, could it be possible that the framerate is slightly different which could result to those slight sync differences?

[Snowknight26]

I think the delay between the audio and video stream is different between the 1st and 2nd EVO. That might be causing my problems too, as the 2nd test I did had EVOs like what I just described.

According to your post:

1st EVO's delay is +200. (200-0=+200)
2nd EVO's delay is -81. (4790204-4790285=-81)

What it seems is that during the middle of the movie, the audio would be off by 119ms (or 281ms, can't think, heads spinning :p).

But then again, maybe I'm totally wrong.

[Thunderbolt8]

I guess if then it would just change at once, with the beginning of the 2nd evo, but there wouldnt be nothing like an average value of both evos. I know that madshi said the value of the 2nd .evo actually dont matter. but maybe during the last updates something happened unintentionally, dont know :S or that disc is just different

[moshmothma]

Any chance eac3to could support mlp from DVD-A? I get an error when I try to decode it. thanks

[killa_kid]

from what i understand of .evo (could be wrong), they are actualy 1 file that is then split (for whatever reason).

Since they are in fact 1 file, that is played as necessary, it is possible a portion of the audio (less then a second) is actually in the 1st file (provided the delay causes this to happen). i have ripped 11 of my HD-DVDs by using DumpHD (AnyDVD for transformers) and then using EVOdemux to demux them into a video and audio file. Then I use only the delay from the 1st evo file. This has resulted in no problems in sync.

When I tried to do them in 2 parts or other methods I had many issues mostly involving audio drift. This method has worked for me, and my understanding could be wrong, but you can always give it a shot and see what happens

PS: I have ripped Batman Begins with TrueHD and got a -200ms delay not +200ms and I have no sync errors. Since you have to subtract the audio delay from the video (since a positive delay means starting to audio a slight bit later, very prominent in The Bourne Supremacy it is 1001ms late)

[Thunderbolt8]

i also applied -200ms, not +200 of course. this would be way off

still, even though it should be mathematically correct, its still a bit off in quite some scenes, noticeably (otherwise I wouldnt have noticed of course). it sometimes differes from the way it looks when playing the movie via powerdvd (yes, I have selected the right track).

[killa_kid]

interesting....i had issues of a similar nature the way i resolved them was by encoding the movie at the 30000/1001 frame rate (the disc default), but when I mux it to mkv i set the frame rate to 24000/1001 (the actual frame rate). may not be the optimal solution, but it worked for me.

[madshi]

So I tried converting the Poseidon TrueHD track (24bit) to DTS and FLAC, but I noticed different lengths. I then compared it to my previous conversions, and the DTS length was different yet again.

eac3to v2.05:
DTS, 5.1 channels, 1:38:44, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

eac3to v1.23:
DTS, 5.1 channels, 1:40:18, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

How do I know which one is the proper one (if any), and why do the DTS transcodes have varying length?

Edit:
I also compared a different DD+ track to various encodes. Source is "E-AC3, 5.1 channels, 1:47:35, 1536kbit/s, 48khz, dialnorm: -27dB" according to eac3to v2.05. Then just for the heck of it, I converted that to AC3 using v2.05.

eac3to v2.05:
DTS, 5.1 channels, 1:48:09, 24 bits, 1536kbit/s, 48khz
AC3, 5.1 channels, 1:47:35, 640kbit/s, 48khz

eac3to v1.23:
DTS, 5.1 channels, 1:49:52, 24 bits, 1536kbit/s, 48khz

:\
That's interesting! Are the DTS tracks in sync when playing them with the video? Not sure where the problem comes from. Maybe Surcode does something wrong?

Wait... Have you encoded the DTS tracks with eac3to's Surcode automation? Or have you manually started Surcode? Or did you use a different DTS encoder?

Another question: Where did you get the runtime information from? Did you throw the v2.05 and v1.23 created DTS files into eac3to v2.05 to get the runtime information? Or did you feed the same DTS file into both v2.05 and v1.23 and they report different lengths for the same track?

[madshi]

a question regarding that trueHD syncing, could it be possible that the track (flac from truehd) is always in sync now, even if evodemux states a delay for it regarding different first pts?
I don't think so. At least that didn't work for me with Bourne Supremecy. Interestingly, with Bourne Supremecy I had to use a delay of 1200-1250ms instead of 1001ms to get good audio sync! I'm wondering whether we need to recalculate the delay by doing "realDelay = evoDemuxDelay * 29.97 / 23.976"?

im trying to remux batman begins and according to evodemux the track should need -200ms of delay.
No, that should be +200ms, just like EvoDemux sais!

[madshi]

I know that madshi said the value of the 2nd .evo actually dont matter.
Right.

It may be different if you reencode both video and audio fo the first and second EVO files separately and then join the reencoded audio and video files. But that'd be a bad idea to start with!

[madshi]

Any chance eac3to could support mlp from DVD-A? I get an error when I try to decode it. thanks
Can you upload a 5MB sample, please?

[shambles]

when removing dialnorm from ac3 tracks, eac3to sets the value to -0db.. shouldn't the value be -31db?

[Thunderbolt8]

No, that should be +200ms, just like EvoDemux sais!
its definately not +200. i applied -200 in the flac and it was fine in some situations when I left it that way in mpc with 0 (=-200) or set +200 (=0, compared to the original state) for other situations.

[xkodi]

Can you upload a 5MB sample, please?

http://samples.mplayerhq.hu/mlp/

http://samples.mplayerhq.hu/DVD-Audio/

http://www.rarewares.org/rja/samples/

[killa_kid]

I'm wondering whether we need to recalculate the delay by doing "realDelay = evoDemuxDelay * 29.97 / 23.976"?

well i checked EVOdemux, and some of the movies are at different frame rates then the actual movie (eg: 59.94) so if you factor that in to the occasion (obviously using the correct source and actual frame rate) you can then do the math.

Out of my 16 HD DVDs, I only have 5 which need a delay (positive or negative) and with doing the math this way I only found 1 where this had an effect (Transformers). Later today I'll try ripping with my previously determined and newly calculated delays and see if it makes a difference or not.

[drmpeg]

I've updated xport to remove the sequence end codes from the demuxed video elementary stream. This avoids having to use TSRemux just for this purpose on concatenated Blu-ray .m2ts files.

Version 1.00

http://www.w6rz.net/xport.zip

I've also looked at the A/V sync issues with seamless branching titles (where multiple .m2ts files are joined together). xport is working correctly, but there are issues with the way the segments are authored. Basically, there's too much audio at the end of each segment. Unfortunately, it can't be avoided, since each segment must end with a full PES packet for audio.

This means there can be as much as 5 milliseconds of extra LPCM audio and as much as 32 milliseconds of extra AC3 audio per segment.

I've also cleaned up the PTS/DTS dumping, so that it can be used to show the extra audio. Here's an example:

C:\xfer>xport -havs 00017tail.m2ts 1 1 1
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 1
Transport Sync Error, skipped 64 bytes, at 0
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xff, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x61, 0x3f
Audio PID = 4352 <0x1100>, type = 0x80
ES descriptor for stream type 0x80 = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x80, 0x61, 0xff
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x29, 0x04, 0x00
Audio PTS = 2529960, 2529960
LPCM Audio Mode = 3/2+lfe
LPCM Audio Bits/sample = 24
LPCM Audio Sample Rate = 48000
Audio PTS = 2530410, 450
Audio PTS = 2530860, 450
Audio PTS = 2531310, 450
Audio PTS = 2531760, 450
Audio PTS = 2532210, 450
Audio PTS = 2532660, 450
Audio PTS = 2533110, 450
Audio PTS = 2533560, 450
Audio PTS = 2534010, 450
Audio PTS = 2534460, 450
Audio PTS = 2534910, 450
Video PTS(B) = 2553813
Audio PTS = 2535360, 450
Audio PTS = 2535810, 450
Audio PTS = 2536260, 450
Video PTS(B) = 2557567, 3754
Audio PTS = 2536710, 450
Audio PTS = 2537160, 450
Audio PTS = 2537610, 450
Audio PTS = 2538060, 450
Audio PTS = 2538510, 450
Audio PTS = 2538960, 450
Audio PTS = 2539410, 450
Audio PTS = 2539860, 450
Audio PTS = 2540310, 450
Audio PTS = 2540760, 450
Audio PTS = 2541210, 450
Audio PTS = 2541660, 450
Audio PTS = 2542110, 450
Audio PTS = 2542560, 450
Audio PTS = 2543010, 450
Audio PTS = 2543460, 450
Audio PTS = 2543910, 450
Video PTS(P) = 2572582, DTS(P) = 2561321, 3754
Audio PTS = 2544360, 450
Audio PTS = 2544810, 450
Audio PTS = 2545260, 450
Audio PTS = 2545710, 450
Audio PTS = 2546160, 450
Audio PTS = 2546610, 450
Audio PTS = 2547060, 450
Video PTS(B) = 2565075, 3754
Audio PTS = 2547510, 450
Audio PTS = 2547960, 450
Audio PTS = 2548410, 450
Audio PTS = 2548860, 450
Video PTS(B) = 2568828, 3753
Audio PTS = 2549310, 450
Video PTS(P) = 2583843, DTS(P) = 2572582, 3754
Audio PTS = 2549760, 450
Audio PTS = 2550210, 450
Audio PTS = 2550660, 450
<big snip>
.
.
Video PTS(P) = 2737747, DTS(P) = 2726486, 3754
Audio PTS = 2701410, 450
Audio PTS = 2701860, 450
Audio PTS = 2702310, 450
Audio PTS = 2702760, 450
Audio PTS = 2703210, 450
Audio PTS = 2703660, 450
Audio PTS = 2704110, 450
Audio PTS = 2704560, 450
Video PTS(B) = 2730240, 3754
Audio PTS = 2705010, 450
Audio PTS = 2705460, 450
Audio PTS = 2705910, 450
Audio PTS = 2706360, 450
Audio PTS = 2706810, 450
Audio PTS = 2707260, 450
Audio PTS = 2707710, 450
Audio PTS = 2708160, 450
Audio PTS = 2708610, 450
Video PTS(B) = 2733993, 3753
Audio PTS = 2709060, 450
Audio PTS = 2709510, 450
Audio PTS = 2709960, 450
Audio PTS = 2710410, 450
Audio PTS = 2710860, 450
Audio PTS = 2711310, 450
Audio PTS = 2711760, 450
Audio PTS = 2712210, 450
Video PTS(P) = 2749008, DTS(P) = 2737747, 3754 <-- last video PTS
Audio PTS = 2712660, 450
Audio PTS = 2713110, 450
Audio PTS = 2713560, 450
Audio PTS = 2714010, 450
Audio PTS = 2714460, 450
Audio PTS = 2714910, 450
Audio PTS = 2715360, 450
Audio PTS = 2715810, 450
Audio PTS = 2716260, 450
Video PTS(B) = 2741501, 3754
Audio PTS = 2716710, 450
Audio PTS = 2717160, 450
Audio PTS = 2717610, 450
Audio PTS = 2718060, 450
Audio PTS = 2718510, 450
Audio PTS = 2718960, 450
Audio PTS = 2719410, 450
Audio PTS = 2719860, 450
Video PTS(B) = 2745255, 3754
Audio PTS = 2720310, 450
Audio PTS = 2720760, 450
Audio PTS = 2721210, 450
Audio PTS = 2721660, 450
Audio PTS = 2722110, 450
Audio PTS = 2722560, 450
Audio PTS = 2723010, 450
Audio PTS = 2723460, 450
Audio PTS = 2723910, 450
Audio PTS = 2724360, 450
Audio PTS = 2724810, 450
Audio PTS = 2725260, 450
Audio PTS = 2725710, 450
Audio PTS = 2726160, 450
Audio PTS = 2726610, 450
Audio PTS = 2727060, 450
Audio PTS = 2727510, 450
Audio PTS = 2727960, 450
Audio PTS = 2728410, 450
Audio PTS = 2728860, 450
Audio PTS = 2729310, 450
Audio PTS = 2729760, 450
Audio PTS = 2730210, 450
Audio PTS = 2730660, 450
Audio PTS = 2731110, 450
Audio PTS = 2731560, 450
Audio PTS = 2732010, 450
Audio PTS = 2732460, 450
Audio PTS = 2732910, 450
Audio PTS = 2733360, 450
Audio PTS = 2733810, 450
Audio PTS = 2734260, 450
Audio PTS = 2734710, 450
Audio PTS = 2735160, 450
Audio PTS = 2735610, 450
Audio PTS = 2736060, 450
Audio PTS = 2736510, 450
Audio PTS = 2736960, 450
Audio PTS = 2737410, 450
Audio PTS = 2737860, 450
Audio PTS = 2738310, 450
Audio PTS = 2738760, 450
Audio PTS = 2739210, 450
Audio PTS = 2739660, 450
Audio PTS = 2740110, 450
Audio PTS = 2740560, 450
Audio PTS = 2741010, 450
Audio PTS = 2741460, 450
Audio PTS = 2741910, 450
Audio PTS = 2742360, 450
Audio PTS = 2742810, 450
Audio PTS = 2743260, 450
Audio PTS = 2743710, 450
Audio PTS = 2744160, 450
Audio PTS = 2744610, 450
Audio PTS = 2745060, 450
Audio PTS = 2745510, 450
Audio PTS = 2745960, 450
Audio PTS = 2746410, 450
Audio PTS = 2746860, 450
Audio PTS = 2747310, 450
Audio PTS = 2747760, 450
Audio PTS = 2748210, 450
Audio PTS = 2748660, 450
Audio PTS = 2749110, 450
Audio PTS = 2749560, 450
Audio PTS = 2750010, 450
Audio PTS = 2750460, 450
Audio PTS = 2750910, 450
Audio PTS = 2751360, 450
Audio PTS = 2751810, 450
Audio PTS = 2752260, 450
Audio PTS = 2752710, 450 <--- last audio PTS

packets for pid 0 <0x0000> = 31, first = 1209, last = 52013
packets for pid 31 <0x001f> = 3, first = 8231, last = 47155
packets for pid 256 <0x0100> = 31, first = 1210, last = 52014
packets for pid 4097 <0x1001> = 32, first = 2486, last = 52045
packets for pid 4113 <0x1011> = 33190, first = 2, last = 49311
packets for pid 4352 <0x1100> = 12096, first = 1, last = 51538
packets for pid 4353 <0x1101> = 1362, first = 243, last = 52079
packets for pid 4354 <0x1102> = 1362, first = 245, last = 52080
packets for pid 4355 <0x1103> = 1362, first = 247, last = 52081
packets for pid 4356 <0x1104> = 372, first = 249, last = 50634
packets for pid 4611 <0x1203> = 2240, first = 3807, last = 48772
packets for pid 8191 <0x1fff> = 2, first = 52082, last = 52083
coded pictures = 52, video fields = 0

C:\xfer>

This is a demux of the last 10 Megabytes of a segment from a seamless branching movie. The last audio PTS is 2752710 and the last video PTS is 2749008. The video ends at 2749008 + 3754 = 2752762. The audio ends at 2752710 + 450 = 2753160. 2753160 - 2752762 = 398. 398 / 90000 = 4.42 milliseconds too much audio.

Here's the AC3 track:

C:\xfer>xport -havs 00017tail.m2ts 1 1 2
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 2
Transport Sync Error, skipped 64 bytes, at 0
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xff, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x61, 0x3f
ES descriptor for stream type 0x80 = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x80, 0x61, 0xff
Audio PID = 4353 <0x1101>, type = 0x81
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x29, 0x04, 0x00
Audio PTS = 2497200, 2497200
Audio PTS = 2500080, 2880
Audio Bitrate = 640000, Audio Sampling Rate = 48000
Audio Mode = 3/2, bsid = 6, bsmod = 0
Video PTS(B) = 2553813
Video PTS(B) = 2557567, 3754
Audio PTS = 2502960, 2880
Audio PTS = 2505840, 2880
Audio PTS = 2508720, 2880
Video PTS(P) = 2572582, DTS(P) = 2561321, 3754
Audio PTS = 2511600, 2880
Video PTS(B) = 2565075, 3754
Audio PTS = 2514480, 2880
Video PTS(B) = 2568828, 3753
Video PTS(P) = 2583843, DTS(P) = 2572582, 3754
Audio PTS = 2517360, 2880
Video PTS(B) = 2576336, 3754
Audio PTS = 2520240, 2880
Video PTS(B) = 2580090, 3754
Audio PTS = 2523120, 2880
Video PTS(P) = 2595105, DTS(P) = 2583843, 3753
Audio PTS = 2526000, 2880
Audio PTS = 2528880, 2880
Video PTS(B) = 2587597, 3754
Audio PTS = 2531760, 2880
Video PTS(B) = 2591351, 3754
Audio PTS = 2534640, 2880
Video PTS(P) = 2606366, DTS(P) = 2595105, 3754
Audio PTS = 2537520, 2880
Video PTS(B) = 2598858, 3753
Audio PTS = 2540400, 2880
Audio PTS = 2543280, 2880
Video PTS(B) = 2602612, 3754
Audio PTS = 2546160, 2880
Video PTS(P) = 2617627, DTS(P) = 2606366, 3754
Audio PTS = 2549040, 2880
Video PTS(B) = 2610120, 3754
Audio PTS = 2551920, 2880
Audio PTS = 2554800, 2880
Video PTS(B) = 2613873, 3753
Audio PTS = 2557680, 2880
Video PTS(P) = 2621381, DTS(P) = 2617627, 3754
17 frames before first I-frame
High Profile
Level = 4.1
Audio PTS = 2560560, 2880
Audio PTS = 2563440, 2880
Audio PTS = 2566320, 2880
Video PTS(P) = 2628888, DTS(P) = 2621381, 3754
First Video PTS = 0x0027ffc5
Audio PTS = 2569200, 2880
Video PTS(B) = 2625135, 3754
Video PTS(P) = 2640150, DTS(P) = 2628888, 3753
Audio PTS = 2572080, 2880
Video PTS(B) = 2632642, 3754
Audio PTS = 2574960, 2880
Video PTS(B) = 2636396, 3754
Audio PTS = 2577840, 2880
Audio PTS = 2580720, 2880
Video PTS(P) = 2651411, DTS(P) = 2640150, 3754
Audio PTS = 2583600, 2880
Video PTS(B) = 2643903, 3753
Audio PTS = 2586480, 2880
Video PTS(B) = 2647657, 3754
Audio PTS = 2589360, 2880
Audio PTS = 2592240, 2880
Video PTS(P) = 2662672, DTS(P) = 2651411, 3754
Audio PTS = 2595120, 2880
Video PTS(B) = 2655165, 3754
Audio PTS = 2598000, 2880
Video PTS(B) = 2658918, 3753
Audio PTS = 2600880, 2880
Audio PTS = 2603760, 2880
Video PTS(P) = 2673933, DTS(P) = 2662672, 3754
Audio PTS = 2606640, 2880
Video PTS(B) = 2666426, 3754
Audio PTS = 2609520, 2880
Video PTS(B) = 2670180, 3754
Audio PTS = 2612400, 2880
Video PTS(P) = 2685195, DTS(P) = 2673933, 3753
Audio PTS = 2615280, 2880
Audio PTS = 2618160, 2880
Video PTS(B) = 2677687, 3754
Audio PTS = 2621040, 2880
Video PTS(B) = 2681441, 3754
Audio PTS = 2623920, 2880
First Audio PTS = 0x0027fe70, -341
Video PTS(P) = 2696456, DTS(P) = 2685195, 3754
Audio PTS = 2626800, 2880
Audio PTS = 2629680, 2880
Audio PTS = 2632560, 2880
Video PTS(B) = 2688948, 3753
Audio PTS = 2635440, 2880
Video PTS(B) = 2692702, 3754
Video PTS(P) = 2703963, DTS(P) = 2696456, 3754
Audio PTS = 2638320, 2880
Audio PTS = 2641200, 2880
Video PTS(B) = 2700210, 3754
Audio PTS = 2644080, 2880
Video PTS(P) = 2715225, DTS(P) = 2703963, 3753
Audio PTS = 2646960, 2880
Video PTS(B) = 2707717, 3754
Audio PTS = 2649840, 2880
Audio PTS = 2652720, 2880
Video PTS(B) = 2711471, 3754
Audio PTS = 2655600, 2880
Video PTS(P) = 2726486, DTS(P) = 2715225, 3754
Audio PTS = 2658480, 2880
Video PTS(B) = 2718978, 3753
Audio PTS = 2661360, 2880
Video PTS(B) = 2722732, 3754
Audio PTS = 2664240, 2880
Audio PTS = 2667120, 2880
Video PTS(P) = 2737747, DTS(P) = 2726486, 3754
Audio PTS = 2670000, 2880
Video PTS(B) = 2730240, 3754
Audio PTS = 2672880, 2880
Video PTS(B) = 2733993, 3753
Audio PTS = 2675760, 2880
Audio PTS = 2678640, 2880
Video PTS(P) = 2749008, DTS(P) = 2737747, 3754 <-- last video PTS
Audio PTS = 2681520, 2880
Video PTS(B) = 2741501, 3754
Audio PTS = 2684400, 2880
Video PTS(B) = 2745255, 3754
Audio PTS = 2687280, 2880
Audio PTS = 2690160, 2880
Audio PTS = 2693040, 2880
Audio PTS = 2695920, 2880
Audio PTS = 2698800, 2880
Audio PTS = 2701680, 2880
Audio PTS = 2704560, 2880
Audio PTS = 2707440, 2880
Audio PTS = 2710320, 2880
Audio PTS = 2713200, 2880
Audio PTS = 2716080, 2880
Audio PTS = 2718960, 2880
Audio PTS = 2721840, 2880
Audio PTS = 2724720, 2880
Audio PTS = 2727600, 2880
Audio PTS = 2730480, 2880
Audio PTS = 2733360, 2880
Audio PTS = 2736240, 2880
Audio PTS = 2739120, 2880
Audio PTS = 2742000, 2880
Audio PTS = 2744880, 2880
Audio PTS = 2747760, 2880
Audio PTS = 2750640, 2880 <-- last audio PTS

packets for pid 0 <0x0000> = 31, first = 1209, last = 52013
packets for pid 31 <0x001f> = 3, first = 8231, last = 47155
packets for pid 256 <0x0100> = 31, first = 1210, last = 52014
packets for pid 4097 <0x1001> = 32, first = 2486, last = 52045
packets for pid 4113 <0x1011> = 33190, first = 2, last = 49311
packets for pid 4352 <0x1100> = 12096, first = 1, last = 51538
packets for pid 4353 <0x1101> = 1362, first = 243, last = 52079
packets for pid 4354 <0x1102> = 1362, first = 245, last = 52080
packets for pid 4355 <0x1103> = 1362, first = 247, last = 52081
packets for pid 4356 <0x1104> = 372, first = 249, last = 50634
packets for pid 4611 <0x1203> = 2240, first = 3807, last = 48772
packets for pid 8191 <0x1fff> = 2, first = 52082, last = 52083
coded pictures = 52, video fields = 0

C:\xfer>

The last audio PTS is 2750640 and the last video PTS is again 2749008. The video ends at 2749008 + 3754 = 2752762. The audio ends at 2750640 + 2880 = 2753520. 2753520 - 2752762 = 758. 758 / 90000 = 8.42 milliseconds too much audio.

The problem is, this extra audio adds up over the course of the many segments required for seamless branching. For a 30 segment movie, there could be up to 150 milliseconds too much LPCM and 960 milliseconds too much AC3. Of course, the average will be about half that.

When the clip is being played with A/V sync, the extra audio is taken care of when the decoder starts the next clip. If the timestamps are far enough apart, the video decoder will repeat a frame to maintain A/V sync.

BTW, you can download a utility to cut the end off of .m2ts files so that you can get the ending PTS's faster than demuxing the whole segment.

http://www.w6rz.net/tail.zip

tail <infile> <outfile> <length>

For example:

tail 00017.m2ts 00017tail.m2ts 10000000

Ron

[Thunderbolt8]

is this the same version as the test version you gave me, ron, or is this again another update?

so this was the reason why xport and mencoder demuxed 1 frame more for each joined part, to have the audio stay in sync? I assume, even if the audio is too long then compared to its original state we dont need to alter it (or the video), because of that additional 1 frame per part everything stays in sync throughout the movie?

thanks for your effort btw.! :)

[madshi]

when removing dialnorm from ac3 tracks, eac3to sets the value to -0db.. shouldn't the value be -31db?
It's not really "-0db", it's zeroed out, which according to the specification has the same effect as setting it to "-31db". Sony doesn't use "-31db" for their Blu-Ray audio tracks. Sony zeroes out the dialnorm fields. So I decided to let eac3to disable dialnorm similar to how Sony is doing it.

[madshi]

its definately not +200. i applied -200 in the flac and it was fine in some situations when I left it that way in mpc with 0 (=-200) or set +200 (=0, compared to the original state) for other situations.
As far as I understand it, the mathematics say it should be +200. Have you tried with +200? Please try it before saying it must be wrong.

[madshi]

well i checked EVOdemux, and some of the movies are at different frame rates then the actual movie (eg: 59.94) so if you factor that in to the occasion (obviously using the correct source and actual frame rate) you can then do the math.

Out of my 16 HD DVDs, I only have 5 which need a delay (positive or negative) and with doing the math this way I only found 1 where this had an effect (Transformers). Later today I'll try ripping with my previously determined and newly calculated delays and see if it makes a difference or not.
Will be interesting to hear your results. I'd really like to find a way to automatically calculate the perfect delay value.

[Snowknight26]

That's interesting! Are the DTS tracks in sync when playing them with the video? Not sure where the problem comes from. Maybe Surcode does something wrong?

Wait... Have you encoded the DTS tracks with eac3to's Surcode automation? Or have you manually started Surcode? Or did you use a different DTS encoder?

Another question: Where did you get the runtime information from? Did you throw the v2.05 and v1.23 created DTS files into eac3to v2.05 to get the runtime information? Or did you feed the same DTS file into both v2.05 and v1.23 and they report different lengths for the same track?

No they aren't, unfortunately.
Yes, used eac3to's Surcode automation.
Runtime for all files is from v2.05. I was comparing the files made by v2.05 and v1.23, but getting the info strictly from v2.05.

[Thunderbolt8]

As far as I understand it, the mathematics say it should be +200. Have you tried with +200? Please try it before saying it must be wrong.
of course I did, but its way off then

[madshi]

http://samples.mplayerhq.hu/mlp/

http://samples.mplayerhq.hu/DVD-Audio/

http://www.rarewares.org/rja/samples/
Thanks, will have a look.

[madshi]

I've updated xport to remove the sequence end codes from the demuxed video elementary stream. This avoids having to use TSRemux just for this purpose on concatenated Blu-ray .m2ts files.
Thanks!! :)

I guess this is mainly meant for reencoding? Wouldn't it be even better to remove the sequence end codes while still leaving the TS structure in place - so that we can just join the TS parts into one big TS file? Or would the timecodes also need to be rewritten to make simple file joining work?

I've also looked at the A/V sync issues with seamless branching titles (where multiple .m2ts files are joined together). xport is working correctly, but there are issues with the way the segments are authored. Basically, there's too much audio at the end of each segment. Unfortunately, it can't be avoided, since each segment must end with a full PES packet for audio.

This means there can be as much as 5 milliseconds of extra LPCM audio and as much as 32 milliseconds of extra AC3 audio per segment.

[...]

The problem is, this extra audio adds up over the course of the many segments required for seamless branching. For a 30 segment movie, there could be up to 150 milliseconds too much LPCM and 960 milliseconds too much AC3. Of course, the average will be about half that.

When the clip is being played with A/V sync, the extra audio is taken care of when the decoder starts the next clip. If the timestamps are far enough apart, the video decoder will repeat a frame to maintain A/V sync.
That's very interesting!!

I'm just thinking about ProjectX. I believe ProjectX checks the timecodes and adds/removes AC3 frames when necessary to keep audio sync perfect when joining multiple VOB files. xport currently always only handles one TS file at a time, right? Would it be much work to enhance xport so that it can handle a specified sequence of TS files? That should allow xport to double check timecodes and remove or duplicate AC3 frames if necessary to avoid cumulated audio delays. What do you think?

Maybe I'm asking too much... :) I don't know how much time you have for doing this kind of stuff. Please don't feel urged to spend hours on this. But of course many of us would greatly welcome if you were able to solve the seamless branching audio sync problem!

--------

BTW, I'm not sure but I think with some movies there may be more than just 5ms LPCM data too much! E.g. I remember when I tried to remux "Ghost in the Shell 2 - Innocence" I had quite some trouble with the joining of the two TS parts. At the join point video stuttered quite a lot while audio was playing fluidly. Only after letting mkvtoolnix rewriting the video timestamps I got it solved more or less. But at the join point I now have about half a second of video where the frames are shown slowed down. I think there was at least half a second of too much LPCM data at the end of the first TS part!

[Thunderbolt8]

btw. any reason why remuxing ratatouille (AVC) from .m2ts into .mkv results into video glitches, which get the audio of sync?

someone reported its the same with meet the robinsons btw., also AVC, seamless branching and an animated movie. has it something to do how animated movies are produced?


p.s. ron, is this improved function for seamless branching movies only restricted to avc or does it work with vc-1 and mpeg2 as well ? (even though I dont know any such seamless branching movie, does 1 already exist?)

[madshi]

No they aren't, unfortunately.
Yes, used eac3to's Surcode automation.
Runtime for all files is from v2.05. I was comparing the files made by v2.05 and v1.23, but getting the info strictly from v2.05.
Hmmmm... One reason why the runtimes differ could be that some of those tracks have zero padding in them while others don't. Can you please run all DTS tracks through v2.05 ("eac3to source.dts dest.dts") and check if v2.05 claims that it removes zero padding for some DTS files? Maybe the runtime of the v1.23 tracks will change once you run the DTS tracks through v2.05?

[Thunderbolt8]

the galapagos HD DVD is 1080i and also has a different framerate (29.97) btw.

[madshi]

btw. any reason why remuxing ratatouille (AVC) from .m2ts into .mkv results into video glitches, which get the audio of sync?
Which remuxing method are you using? I've always said that demuxing h264 and then muxing it with mp4box/creator/mkvtoolnix is a bad idea. But somehow nobody listens to me. I strongly recommend using Haali's filters to do any h264 remuxing. Too bad that mkvtoolnix can't handle Blu-Ray h264 remuxes done by the latest Haali filters, but hopefully Mosu will fix that soon.

[Thunderbolt8]

I did also try that as well, with gdsmux. I packed the whole .m2ts file into gdsmux. but when only selecting the video stream it just stops (the nice stop error), for both version, the old and new one. so I always have to add at least one audio stream.
when its finished the file looks nice, it has the correct length and is also in sync. but you cant jump back and forth in the stream at all. and you also cant remux the file with mkvmerge again, the final file will result in a neverending processing when double clicking, but no picture or sound will occur. so I cant really use gdsmux.

and these were the only 2 movies with glitches I had so far. no other avc/h264 hddvd, blu-ray or hdtv source resulted in glitches so far that way.

[Snowknight26]

Hmmmm... One reason why the runtimes differ could be that some of those tracks have zero padding in them while others don't. Can you please run all DTS tracks through v2.05 ("eac3to source.dts dest.dts") and check if v2.05 claims that it removes zero padding for some DTS files? Maybe the runtime of the v1.23 tracks will change once you run the DTS tracks through v2.05?


eac3to.exe "G:\Encoding Tools\temp\poseidon.new.dts" "G:\Encoding Tools\temp\poseidon.new.redone.dts"
DTS, 5.1 channels, 1:38:44, 24 bits, 1536kbit/s, 48khz
Creating/writing file "G:\Encoding Tools\temp\poseidon.new.redone.dts"...
Removing DTS zero padding...
Done.

eac3to.exe "G:\Encoding Tools\temp\poseidon.old.dts" "G:\Encoding Tools\temp\poseidon.old.redone.dts"
DTS, 5.1 channels, 1:40:18, 24 bits, 1536kbit/s, 48khz
Creating/writing file "G:\Encoding Tools\temp\poseidon.old.redone.dts"...
Removing DTS zero padding...
Done.

eac3to.exe "G:\Encoding Tools\temp\poseidon.new.redone.dts"
DTS, 5.1 channels, 1:38:36, 24 bits, 1536kbit/s, 48khz

eac3to.exe "G:\Encoding Tools\temp\poseidon.old.redone.dts"
DTS, 5.1 channels, 1:38:35, 24 bits, 1536kbit/s, 48khz

[honai]

I've always said that demuxing h264 and then muxing it with mp4box/creator/mkvtoolnix is a bad idea.

Why is that? Done this on all my Blu-ray discs, never had any problems, video plays smooth and in sync.

[madshi]

I did also try that as well, with gdsmux. I packed the whole .m2ts file into gdsmux. but when only selecting the video stream it just stops (the nice stop error), for both version, the old and new one. so I always have to add at least one audio stream.
when its finished the file looks nice, it has the correct length and is also in sync. but you cant jump back and forth in the stream at all. and you also cant remux the file with mkvmerge again, the final file will result in a neverending processing when double clicking, but no picture or sound will occur. so I cant really use gdsmux.
Yeah, as I said, mkvtoolnix doesn't like the Haali/gdsmux remuxed MKVs. But I hope Mosu will fix that soon. Hopefully running the MKV through a fixed mkvtoolnix with rewriting the timestamps will also give us seeking back.

[madshi]

Why is that? Done this on all my Blu-ray discs, never had any problems, video plays smooth and in sync.
Try it with Equilibrium, then you know why. The same problem occurs with some German h264 broadcasts. Anyway, that's out of topic here...