Segmented AC3 Movie Error

[Sakuya]

Hi, I have a huge problem with this movie I have that is cut into 2 parts and has AC3 5.1 sound. I want to put it on DVD. I opened Virtualdub and then appended the two segments together. Then I selected the Video as Direct Stream Copy and saved as an AVI. I opened VirtualdubMOD and appended the two segments. I then demuxed the AC3. I then converted the AVI to M2V in TMPGEnc Plus. The length as shown in Windows Media Player Classic is 1 hour 46 minutes and 25 seconds. In GSpot and Virtualdub, it says the same thing. But in MPEG-VCR, it says the M2V file is 1 hour 46 minutes and 18 seconds. I tried to author to DVD using DVDAuthorGUI but the DVD stops playing right where segment 1 is supposed to end. When I authored with IFOedit, same results. Why is this? :scared: I played the M2V file and it looks fine. The AC3 file also played fine and is really seamless at the point where the segments join. I didn't play them together though because I didn't know how.

So then I tried to convert the 2 video files to M2V separately. I then used VirtualdubMOD to demux the AC3 audio streams. So now, I have:

2 M2V files
2 AC3 files

The length for part 1 is 52 minutes and 35 seconds. The length for part 2 is 53 minutes 49 seconds. That was shown in Windows Media Player Classic. However, in MPEG-VCR, it said this:

PART1.M2V - 52 minutes and 32 seconds
PART1.AC3 - 52 minutes and 35 seconds

PART2.M2V - 53 minutes and 46 seconds
PART2.M2V - 53 minutes and 50 seconds

Why is this? I used DVDAuthorGUI to author the DVD. However, when I play the DVD, same results as my first try above. I really don't get this. I tried authoring with DVD-lab PRO and again it shows that the M2V file is not the same length as the AC3 file. And after multiplexing, the output folder was empty.

Next, I tried to author the two segments by using TMPGEnc DVD Authoring. I added the two segments to the same track. There was a half second pause (I wonder why it isn't seamless?). But I have a subtitle stream too that TDA won't support so TDA won't work for me.

In IFOedit, I found out that it won't let me add two clips. So I authored each segment separately. I then went to DVD Shrink and re-authored by loading the two segments together. I burned it to DVD+RW. When playing the DVD, I noticed that the first segment is track 1 and the second segment is on track 2. And there was a 1 second pause, slightly longer than TDA's result.

Now, I still have to wonder what the problem is and if there is a better solution that might allow me to get a seamless movie as well as still menus and subtitles. DVDAuthorGUI would work because it has all I need but when authoring the two segments separately, there was an error in the authoring process. I contacted the creator of the program but he hasn't responded yet. So if you have any advice, anything would be appreciated. Thanks. :(

[Matthew]

I wouldn't read much into the differing lengths being reported...I'd think that's just program oddities.

Try running the AC3 through BeSpliced and see if it reports any errors. It's not uncommon for there to be duplicate bytes around the AC3 join point. The result of this is non-spec AC3, and that could cause problems.

[Sakuya]

Would that be the joined AC3 or the segmented AC3?

[mudda_t]

What was the format of your original files?
.
Did your second file start at 0min 0sec or something like 45min 35sec?
.
The 3-5sec difference is nothing to worry about. Trying to fix that will cause you more problems and headaches.
.
Dvdshrink didn't actually join the files, it created different title sets vts_01_1, vts_02_1. Almost all players will pause between titlesets.

[Matthew]

Originally posted by Sakuya
Would that be the joined AC3 or the segmented AC3?

The joined AC3, if there is a problem around the join point you'll get an error message something like "sync found after 1794 bytes" for a 448 kbps AC3. The framesize is 1792 (4*448) so that would mean the 2 bytes at the end of AC3 file 1 are the same as the 2 bytes at the start of AC3 file 2.

[Sakuya]

Originally posted by mudda_t
What was the format of your original files?
.
Did your second file start at 0min 0sec or something like 45min 35sec?
.
The 3-5sec difference is nothing to worry about. Trying to fix that will cause you more problems and headaches.
.
Dvdshrink didn't actually join the files, it created different title sets vts_01_1, vts_02_1. Almost all players will pause between titlesets.

The format of the original files is AVI in XviD. The second file starts at 0 minutes and 0 seconds. I don't think there is a problem with the AC3 because playing the merged AC3 has no problems at all. It plays seamlessly with no pauses at all. I think it's the video problem because the length is shorter than the audio but then I just don't understand why Gspot, WMP, and Virtualdub says the length is 1:46:25 and MPEG editting software says otherwise.

[Sakuya]

Originally posted by Matthew
Try running the AC3 through BeSpliced and see if it reports any errors. It's not uncommon for there to be duplicate bytes around the AC3 join point. The result of this is non-spec AC3, and that could cause problems.

I dragged the merged AC3 file into BeSplice and fixed the file. Here is the log entry after the process:

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : E:\Burning\VIDEO_TS\amgmerge.ac3
[00:00:00:000] | Output Prefix : E:\Burning\VIDEO_TS\amgmerge_Fixed
[00:00:00:000] +---------------------
[00:52:35:232] Stream error : Sync found after 1542 bytes
[01:46:25:152] | Writing E:\Burning\VIDEO_TS\amgmerge_Fixed01.ac3
[01:46:25:152] +---------------------
[01:46:25:152] Operation Completed !
[00:00:27:000] <-- Process Duration
Logging ends : 04/20/04 , 17:58:35.

What does it mean? :confused: And there was no new AC3 file after that process probably due to the error.

[Matthew]

There should be a fixed file there...setting that aside for a moment...

This is a 384 kbps AC3 correct?

4 x 384 = 1536. That means each frame is 1536 bytes.

1542-1536 = 6

I bet if you delete the 6 bytes at the end of AC3 1 and then join AC3 1 + AC3 2 the stream error will go away.

All that's happened is that the AC3 hasn't been cleanly cut and there is a 6 byte overlap.

[Sakuya]

Just a quick reminder that the file I went through BeSplice was the AC3 with the 2 segments joined. I got it by appending the two movie segments in VDubMOD and then demuxing the AC3. You said:

4 x 384 = 1536

What does the 4 represent? And how do I delete the 6 bytes? That's weird, it doesn't sound like there is an overlap. :confused:

[Matthew]

Yeah that's how I expected you'd join them. A file joining app using on the original CD1 and CD2 AC3s would produce exactly the same result btw.

4 x audio bitrate = size of each frame in bytes. So each frame of a 448 AC3 file is 4 x 448 = 1792

I'm not guessing at this overlap thing, I'm talking from experience.

You can delete the 6 bytes using a hexeditor like ultraedit.

From memory besliced might be systematically one byte off so it might be 5 or 7 bytes. Just use your eyes in the hex editor, and delete the duplicate characters (compare end of AC3 1 and start of AC3 2 side by side).

[Sakuya]

I can't find any duplicate characters. I have a screen capture but I don't know how to attach that here.

[Matthew]

I'll PM you an ftp address.

This is a 384 kbps ac3 file right? file->file information in vdubmod will tell you that.

Also is there any overlap in the video? In such cases there wouldn't be any duplicate bytes, because the partial AC3 frames would be unrelated.

[Sakuya]

Yes, it is 384 kbps. And I uploaded the image, I hope it's in the right directory. As in overlap for the video, no, there appears to be no repeated pictures.

[Matthew]

mmm...you're right, how odd.

From the screenshot you've given me I can tell the following:

AC3 1 is 151450089, which equates to 98600 full frames (151449600 bytes) + 489 bytes of a frame at the end.

Ac3 2 is 155037696, which equates to 100936 full frames. And it looks like it starts on a frame too (the .w).

This in itself makes little sense, as a huge chunk of a frame is missing.

Additionally, those 4 20s in a row look decidely like corruption. They should probably be 00s instead.

Do you see lots of other 20s in that second file as well? Just search for 20 20 20 20

Edit: also, run just AC3 #2 through bespliced and post the errors.

[Sakuya]

No, I think it's just in that row. As for BeSplice using AC3 part 2, no errors found. Here is the log entry:

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : E:\Burning\VIDEO_TS\amgpart2.ac3
[00:00:00:000] | Output Prefix : E:\Burning\VIDEO_TS\amgpart2_Fixed
[00:00:00:000] +---------------------
[00:53:49:952] | Writing E:\Burning\VIDEO_TS\amgpart2_Fixed01.ac3
[00:53:49:952] +---------------------
[00:53:49:952] Operation Completed !
[00:00:38:000] <-- Process Duration
Logging ends : 04/20/04 , 19:57:41.

Same thing for part 1 too. Strange. :eek:

Edit:
I found a tons of repeated numbers at the end of PART2.AC3 in Ultraedit. But they're not 20. Want a screencapture?

[Matthew]

If it's at the end then a screencapture isn't necessary...the junk data shouldn't do any harm.

Also, BeSplit will just delete junk at the end without errors. Hence the fixed AC3 #1 should be (439 bytes) smaller, but this won't be reported in the log.

What is odd is that no stream error was reported for the start of AC3 #2. The implication is that the skipped data (1542 byes) is all in file 1 at the end. But the numbers as I have done them don't seem to add up.

What is the size (in bytes) of AC3 #1 before and after running it through besliced?

[Sakuya]

Part1 Before: 147,901KB
Part1 After: 147,900KB

1KB difference, maybe it is the video's problem. :scared:

Edit: You know for the first part of the AC3 file which I took a screencapture of in Ultraedit? Well, at the last row, the numbers ended in the middle right? Well, I checked the part part of the AC3 file that went through BeSplice and the space disappeared. The space is gone but it seems to be entirely different numbers.

[Matthew]

Not in kilobytes, bytes ;)

Right click, properties, copy paste number of bytes next to "size".
:D

[Sakuya]

PART1 Before: 151,450,089 bytes
PART1 After: 151,449,600 bytes

By the way, I added some info to the post above.

[Matthew]

Well, my calcs were correct - there is 489 bytes of junk (well, a partial frame) at the end of AC3 #1 and bespliced deleted these.

Now what this means is there should be junk at the beginning of AC3 #2 in the order of 1542-489=1053. But there isn't.

Rather weird.

Oh well, for seamless transition the appropriate solution is to take the 2 fixed files and join them.

This doesn't answer the question of how the 439 bytes got there (perhaps some video frames are missing - that would explain it), and I'm sure there will be desync (which you probably won't notice anyway).

edit: one last thought, it's possible that the last (partial) frame in CD1 is the same as the first frame in CD2. To see, you could just seatch CD1 AC3 for 0B 77 09 0F 1C and see if it returns the start of the last (partial) frame.

[Sakuya]

I don't get how to do that to the AC3 file. The first few codes for the original unfixed CD2 is: 0B 77 09 0F 1C

However, the last few codes for unfixed CD1 is not that. Instead, I find that code in CD1 in the middle somewhere. Anyway, is there a good reliable AC3 joiner somewhere? Does UltraEdit join AC3s?

[Matthew]

Purely by chance the hex is likely to be replicated elsewhere, but I was interested in whether it was right near the end of the unfixed Ac3 #1.

Anyway, you can use besplit to join...

But any file joiner will do :)

I use http://www.martinstoeckli.ch/splitter/splitter.html at the command-line.

splitter.exe file.ac3.001 C:\files /unsplit /silent /noheader

The files would be file.ac3.001, file.ac3.002, file.ac3.003, file.ac3.004, etc

If for some reason the rest of that partial frame (the rest of the 439 frame) should be there at the start of CD2 but isn't (e.g. because the CD2 avi was demuxed, the ac3 fixed and then re-muxed back in), then for perfect sync you'd want to join ac3 #1 + 1 frame dummy (Bespliced will make one for you) + ac3 #2. It's only 32 ms desync and you shouldn't notice it, but if you want to be anal :)

[Sakuya]

Frame dummy of AC3 1? I'm terribly confused. Also, that site says Splitter Light 4.0. It's ok if I use that?

[Matthew]

Yeah Splitter Light is the one :)

The dummy is just a one frame AC3 to replace the frame you lost (if indeed you did lose it). It'll be 1536 bytes :) The idea is to stop every audio frame after the split point from being 1 frame (32ms) behind where it should be.

[Sakuya]

Is it automatic in the sense where I just click a button? Still clueless. :confused:

[Matthew]

Lets say part1.ac3=fixed AC3 #1 and part2.ac3=fixed AC3 #2

You can create a dummy file by take part1.ac3 and dragging it into the BeSpliced window. Select the "dummy" option and a tiny dummy AC3 will be created.

Now,
rename part1.ac3 to file.ac3.001
rename the tiny dummy file to file.ac3.002
rename part2.ac3 to file.ac3.003

Place splitter.exe in the same directory as these files. In a DOS box navigate to this directory and type:

splitter.exe file.ac3.001 C:\ /unsplit /silent /noheader

The joined file will be in C:\ as file.ac3

That's it :)

Now if you don't want to use the dummy, and that may be the best approach - it's hard to tell, then you'd do the same as the above except part1.ac3 would be renamed to file.ac3.001 and part2.ac3 would be renames to file.ac3.002.

[Sakuya]

Thanks a lot! One last question though. :) What does the dummy AC3 do? Would there be an extra/repeated segment in the outputted audio? Why would it make the audio sync up when using the dummy AC3 along with the two segments of AC3?

I just want to learn all I can so in case it happens again, I would know what to do. Is this a common problem for movies with AC3 sound to be split in 2 parts? I have another movie which is split into, guess what; 3 parts. Haven't started on the project so I wouldn't know if it has this problem or not. But thanks a lot for helping me because you're the only one that have come up with a solution for me. :p

Edit:
Where is the DOS box? Nevermind, I found it by going to CMD. And I managed to open the directory and drive as well. :D I think it outputted.

[Matthew]

The case you have is unusual...but it isn't uncommon for there to be overlapping bytes, maybe missing bytes sometimes (even 1 missing byte means whole frame is lost). Also, if there are overlapping video frames, you'd want to delete those from CD1 before extracting audio or encoding video.

I'll explain the reason for the dummy...

Lets say the original movie had 501 audio frames.

If it's split in the middle (exactly, this is theoretical only of course), the first avi will have 250.5 and the second avi will have 250.5 frames.

Now, when joined back togeth the AC3 stream should be all fine and dandy and have 501 frames.

But what if, lets say, joe blow decides to take CD2.avi, extract the video and audio, fix the AC3 stream and then remux. Well, when the AC3 stream is fixed the half-frame at the start will be lost (half a frame can't be decoded).

You can't just join the CD1 and CD2 AC3s because you have that half frame at the end of CD1 left all on its own (desperate and dateless). So you need to fix it and then join it.

So you are joining 2 fixed files of 250 frames, making a stream of 500 frames. But the original stream was 501 frames. One has been lost at the join point meaning that from the middle onwards the audio is 1 frame behind where it should be. That means desync - you shouldn't notice it though. By inserting the 1 frame dummy this desync won't be there.

Of course, I don't know what has happened in your case, it may be something else that explains the odd circumstances. But you'd be unlucky to experience these exact circumstances again.

As long as you delete any dupe video frames before your operations are performed, *in the normal course* you should experience only 2 possible and fixable besplit errors on the joined AC3:
1. Sync found after XYZ bytes, where XYZ>framesize (1536 for 384 kbps). Delete overlapping bytes using hexeditor and join CD1 + CD2 Ac3s.
2. Sync found after XYZ bytes, where XYZ<framesize (1536 for 384 kbps). For some reason bytes have been left out, join *fixed* CD1 AC3 + dummy + fixed CD2 AC3.

Hope that makes sense :)

[Sakuya]

Thanks. It's authoring now. I hope it works! ;)

Edit:
It worked, it worked! I'm so happy! Thank you so much! It plays seamlessly now! :D

[Sakuya]

Ok, for the next movie which is divided into 3 parts this time (again with AC3 audio), I get the same problem. I append all the segments in VDubMOD and save as AVI. I convert video-only to M2V. I extract the AC3 file. When I run the AC3 file of all the parts in BeSpliced:

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : E:\Burning\VIDEO_TS\arrestmovie.ac3
[00:00:00:000] | Output Prefix : E:\Burning\VIDEO_TS\arrestmovie_Fixed
[00:00:00:000] +---------------------
[00:28:30:560] Stream error : Sync found after 609 bytes
[01:01:01:888] Stream error : Sync found after 1731 bytes
[01:28:31:040] | Writing E:\Burning\VIDEO_TS\arrestmovie_Fixed01.ac3
[01:28:31:040] +---------------------
[01:28:31:040] Operation Completed !
[00:00:11:000] <-- Process Duration
Logging ends : 04/23/04 , 22:16:26.

What does that mean? Since the output is fixed, would it work? Where should I insert the dummy file? Which parts should I make a dummy file of? :confused:

[Matthew]

Yes, the output would import fine, but it would be out of sync (dunno if you'd notice though).

Second join seems really simple. 1731 bytes is close to 1 frame (1792 byes for 448 kbps) so you use a dummy at that join point.

First join is odd once again - you sure do pick 'em :p I haven't come across such odd joins except where there is overlapping video frames.

I'd say, join CD1+CD2+dummy+CD3 and be sure to preview the output for sync issues before burning. You don't have to fix the individual AC3s using besliced, you can run it on the joined file to get rid of the junk - the result will be the same as if you joined the fixed files.

Use the first ac3 to make the dummy, because you want the dummy to have silence in it, and you find that at the start of a movie.

[Sakuya]

Wouldn't there need to be 2 dummies in this case because there are 2 sync problems? The first sync error appears when I fix the CD2 alone. The second error appears in CD3.CD1 is fine. When I fix the merged AC3 with all 3 segments, it has those 2 errors together as shown above. So why doesn't it need 2 dummies?

And yes, I am so unlucky with these and other stuffs. They just don't like me, I swear. ;)

[Matthew]

Well you don't know why there is ~600 bytes, and that complicates matters.

Looking at it on a simplistic level 609 bytes equates to ~11 ms (609/1792*32). So if you don't use a dummy, the fixed joined audio will be out of sync by 11 ms compared to the unfixed joined audio.

If you do use a dummy, the audio will be out of sync by 32-11=21 ms

What is best comes back to why there is only a 609 bytes sync error and not one around 1792.

[Sakuya]

Thanks, I joined them and ran the merged AC3 in BeSpliced again and there are no stream/sync errors. Thanks a lot! You're a huge lifesaver! :D

[Sakuya]

Actually, I think there is an error when I am authoring my DVD. It says:

Audio pts for channel 32 moves backwards, please remultiplex input

:( Maybe the dummy is supposed to go in another place? I have it like this: CD1, CD2, dummy, CD3

Since there are 2 sync errors, shouldn't it placed some other place? :

Edit:
Actually, despite it saying that, it works. That's weird. Anyway, thanks. :o

[Matthew]

I'll take a guess and say that the AC3 is timestamped, and when the authoring app gets to the point of the dummy, it detects the discontinuity in timestamps and whinges as a result.

I've used these streams with Maestro, and it's never complained. It parses each frame of the audio when it's imported, too :)