DBZ audio sync issue, remastered sets. different delays NTSC DVD

[xekon]

I am ripping and encoding the Dragon Ball Z Orange Box remastered sets (the only set that has All 291 episodes with Bruce Faulconer score/track)
and using the audio from it on the R2 dragonbox

I am having a problem where the audio is slightly out of sync.(the track I am trying to use is the stereo 2 channel english, Faulconer Funi Dub)
The only solution I have found is to fix it manually for every episode using DelayAudio, but there has to be an easier way than this.

The content is mostly film, DGINDEX report 99.99% film, except I believe the eyecatch in the middle of the episode,
and some frames for a short amount of time before episodes padding frames maybe.

I cut using AlignedSplice. leaving just the episode without the opening, eyecatch, or ending.

I am then ripping and encoding the Japanese TOEI R2 DragonBox, on this one audio sync is irrelevant I am only encoding the video.

my process:

I have AnyDVD installed and active, I use ripit4me to rip the dvds. I rip the dvd using ripit4me(dvdDecrypter is set to use ElbyCDIO)

Then I have the IFOS and VOBS on my harddisk. I then use pgcdemux to open the ifo using mode by PGC and select demux video stream and demux
all audio streams check boxes, I click the Check A/V delay button, it reports 0ms delay with "by PGC"
once extracted I get three ac3 files and a m2v video file. I renamed the ac3 file that is the track that I want to 001.ac3 and renamed the
.m2v file to 001.m2v

the .m2v i extracted from the DVD using pgcdemux is of the entire disc, so the opening audio delay is 0ms, and all episodes are
lumped sequentially in the single .m2v file.

I found it odd that each episode per disc starts out with the same delay for all 3 streams, but is different for the other 3/4 cells.
I am assuming that if they had added silence to these streams in between cells that I would not be having to fix it with a different value delayaudio() per cell






The delays I posted above are at the 4cells of the first episode on season9 disc1.
I just wanted to show that the delay for the audio changes throughout the episode, this may be normal for a dvd, but it seemed odd to me.
The .m2v & .ac3 file I am working with has an opening delay of 0ms because I extract the entire PGC title.

so now I have my .ac3 file and .m2v file. I now load the .m2v file into DGIndex and with field operation set to HonorPulldown Flags
I save the project which generates a .d2v file for use with avisynth.

now my first script, for the faulconer audio track dbz.avs(Season1 Disc1, trim numbers correspond with 7th episode.):

LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\s9d1\049.ac3")
V = MPEG2Source("F:\s9d1\049.d2v")
AudioDub(V, A)
AlignedSplice(Trim(3300, 12400).DelayAudio(0.102), Trim(12401, 19836).DelayAudio(0.161), Trim(20334, 28749).DelayAudio(0.149), Trim(28750, 37175).DelayAudio(0.121))

dbz-go.bat (only need audio encoded, will be using R2 dragonbox video):

F:\AviSynth\avs2pipe -wav dbz.avs | qaac --tvbr 90 --quality 2 --rate keep --ignorelength - -o job.m4a

===================================
Also my audio video sync issue happens with just the video and audio of the english remastered episode,
before even worrying about muxing the track to the japanesse R2 dragonbox, you can see the delay by running the script, or viewing it in AvsPmod.

here is my current test.avs script, I open this with AvsPmod:

LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\s9d1\049.ac3")
V = MPEG2Source("F:\s9d1\049.d2v")
AudioDub(V, A)
AlignedSplice(Trim(3300, 12400).DelayAudio(0.102), Trim(12401, 19836).DelayAudio(0.161), Trim(20334, 28749).DelayAudio(0.149), Trim(28750, 37175).DelayAudio(0.121))
ConvertToRGB()
AudioGraph(2)

I am assuming the timing will be off according to an amount equal to a number of frames

the episode I am currently working on lined up after a change of 9 frames, so thats what the 9 in the following formula represents

(9/(30000/1001))+celloffset = delay to apply to that cell.

Using this method I could get the entire episode to line up perfectly.
The cell offsets were reported when loading the main .ifo file in PGCDemux, select "single cell" then find the cells that are roughly 5 minutes,
for DBZ there are 4 cells per episode.

I am curious as to why it said the opening delay for the entire PGC had a delay of 0ms when it is actually a delay of roughly 9 frames.

If I can figure out where this delay came from then I could automate this entire process a lot easier and I wouldnt even need to use audiograph
to figure out how many frames the audio is off by on every single episode.

so for the episode I just tried, season9 disc1, episode1.
PGCDemux reported and offset of
cell1: -213 so: -0.213+(9/(30000/1001)) = 0.102
cell2: -139 so: -0.139+(9/(30000/1001)) = 0.161
cell3: -151 so: -0.151+(9/(30000/1001)) = 0.149
cell4: -179 so: -0.179+(9/(30000/1001)) = 0.121

so in my script I used the following and the audio is perfectly in sync for the entire episode.

AlignedSplice(Trim(3300, 12400).DelayAudio(0.102), Trim(12401, 19836).DelayAudio(0.161), Trim(20334, 28749).DelayAudio(0.149), Trim(28750, 37175).DelayAudio(0.121))

Now if I can only understand where that 9frames delay came from?

[manono]

When you demux by PGC and play your script, is it off by the same amount all the way through? Or does the asynch get worse as the episodes go along? - is it progressive? I think you've thrown a red herring into the mix by messing around demuxing by cells. It's completely normal for different cells to have differing delays. Has nothing to do with your main problem (usually).

Does demuxing by VOB ID give you complete episodes? Would you prefer doing that? If you create a PGC VOB, is that in synch?

Forget all those trims, just play the whole thing through your script. Is there a delay? Is the delay constant?

Sometimes it will get everything back in synch if you don't use PGCDemux but just DGIndex, and rather than beginning at the very beginning, use the '[' button to cut off several black frames at the very beginning (maybe the 9 you mentioned). Of course, if that works it points to an incomplete decrypt as there are cells at the very beginning with no audio. Sometimes running your decrypted VOBs through FixVTS corrects that particular problem.

[xekon]

That may have been my fault, I dont think I explained it completely clear. I did not demux by cell. I demuxed the entire PGC title.

the pictures showing the "single cell" audio offsets, was me just checking offsets by cell using pgcdemux, i didnt actually demux those cells, I only checked the offsets of the cells.

for the first cell of every episode, all three streams have an equal offset, but on the remaining 3 cell, all 3 streams for that cell do not have the same offset, this is what I found to be the most strange. not the different offsets per cell necesarrily, but that the offsets were different for the streams per cell and the cells themselves(how is that even possible, unless theres gaps in audio playback for certain streams between cells)

Also in the above screenshots, the audio track I am interested in keeping is Audio_2 0x81

AlignedSplice(Trim(3300, 12400).DelayAudio(0.102), Trim(12401, 19836).DelayAudio(0.161), Trim(20334, 28749).DelayAudio(0.149), Trim(28750, 37175).DelayAudio(0.121))

so I am using the entire PGC as you said, if I comment out the above line then the audio sync is off by different amounts throughout the episode.

I really Liked the idea of using just DGIndex like you pointed out(without using pgcdemux) however I needed to strip the additional angle or DGIndex attempts to play both angles simulataneously.
I did not even think about using the '[' never used it before. I am also inclined to agree that it could be an incomplete decrypt.
I am going to give re-decrypting a try and I am also going to try using the '[' key
I will also try FixVTS!

I will also see if the delay gets larger as you get into farther episodes on the same disc.

Thank you for all of your Help I very much appreciate it. I think the audio delays per cell will have to be applied, because the delays go up then down, etc. if the delays for all 3 streams were the same for cells 2,3,4, like they are for the first cell then I would think that it is only a decryption issue.

I will post back after trying all of the things you mention and let you know my findings.

[manono]

Like I said, virtually every cell after the first one of any retail DVD ever released has delays and it means nothing. Just check the next DVD you have on the hard drive.

Based on your description it sounds to me as if there are unreferenced cells scattered throughout and that's one of the things FixVTS is designed to get rid of. That could easily explain the delay increasing, or at least changing, as the episodes go along.

Right, it's multi-angle. Sorry, I forgot. The unwanted angle(s) can be gotten rid of using DVDDecrypter in IFO Mode (or RipIt4Me which also runs FixVTS afterwards). Or after the decrypt using PGCEdit or IFOEdit if you need the menus back. Or, as you said, using PGCDemux.

[xekon]

Originally Posted by manono

Like I said, virtually every cell after the first one of any retail DVD ever released has delays and it means nothing. Just check the next DVD you have on the hard drive.

Ah ok, I just wasn't sure if I explained it clearly was all, thank you very much for telling me that.

Originally Posted by manono

Based on your description it sounds to me as if there are unreferenced cells scattered throughout and that's one of the things FixVTS is designed to get rid of. That could easily explain the delay increasing, or at least changing, as the episodes go along.

Right, it's multi-angle. Sorry, I forgot. The unwanted angle(s) can be gotten rid of using DVDDecrypter in IFO Mode (or RipIt4Me which also runs FixVTS afterwards). Or after the decrypt using PGCEdit or IFOEdit if you need the menus back. Or, as you said, using PGCDemux.

ahh I thought step4 cleanup vobs looked pretty similar to fixvts.

I started back at square one.
I ran it through ripit4me again with anydvd active.
Here is the logs, it shows that it was protected:

RipIt4Me.log: http://pastebin.com/dSp3Rr3R

DVDDecrypter.log: http://pastebin.com/ZaA0fund

I did not use PGCDemux this time. I turned on Mutli Angle processing for DVDDecrypter in File Mode which is what Ripit4me uses.

I opened all 8 vobs directly with DGIndex, honor pulldown flags mode, and saved the .d2v

After this process there is 42 black frames (0-41) at the opening.

I changed my script to not use Trim
it just plays the entire thing, audio is off quite a bit:

LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\DRAGON_BALL_Z_S9_D1\001.ac3")
V = MPEG2Source("F:\DRAGON_BALL_Z_S9_D1\001.d2v")
AudioDub(V, A)
ConvertToRGB()
AudioGraph(2)

here are the delays roughly(not exact but close) that it takes to correct the sync at each episode:

frames 0-41 black
1st episode: DelayAudio(0.4) (the delays seems to work throughout the entire episode)
frames 43498-43596 black (98 frames)
2nd episode: DelayAudio(1.5)
frames 87068-87166 black (98 frames)
3rd episode: DelayAudio(2.4)
frames 130638-130736 black (98 frames)
4th episode: DelayAudio(3.3)
frames 174208-174306 black (98 frames)
5th episode: DelayAudio(4.1)
frames 217778-217876 black (98 frames)
6th episode: DelayAudio(5.3)

I used this script, and just adjusted the delay at every episode until it was close to lining up:

LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\DRAGON_BALL_Z_S9_D1\049.ac3")
V = MPEG2Source("F:\DRAGON_BALL_Z_S9_D1\049.d2v")
AudioDub(V, A)
DelayAudio(5.3)
ConvertToRGB()
AudioGraph(2)

It gets more off sync between every episode, I remember you said to use '[' key in dgindex, but when I use the left right arrow keys it jumps more than one frame, the only way I can line it up perfectly after the black frames is if it went one frame at a time. Also if this worked I would need to do each episode separately, because the delay increases between every episode.

Is there anything else I can try?

Also another thing that worries me is that maybe some of the black frames are supposed to be there? but there might be too many.
the delay that fixed the first episode was 0.4 by my math that is 12 frames, not the 42 blank frames that I have.

(12/(30000/1001))=0.4

just as I wrote the last paragraphed I realized/remembered something. before running it through ripit4me

there was 2 titles I could choose from (if you view them in PgcDemux)
PGC #01 --> 2:49:54.19
PGC #02 --> 2:15:28.04

the second PGC is for a marathon mode that the dvd has which skips the previous episode recap.

now, after ripit4me there is 1 title (if you view them in PgcDemux)
PGC # 01 --> 02:51:33.04

I mention this because before if I extracted PGC #02 there were only 30 Black Frames before the episode, now that I only have PGC #01 there are 42 black frames and 42-30 = 12frames (roughly the amount of delay I have to use to get the first episode to line up.)

I am going to try ripit4me again but with full dvd instead of main movie mode.(This may not fix anything, it might be that for whatever reason ripit4me is missing some of those black frames that it should be removing.)

edit: Now that I used ripit4me on the full dvd instead of main movie, I have the two PGC titles again.
PGC #01 --> 2:49:54.19
PGC #02 --> 2:15:28.04

Now that it has been ran through ripit4me, I tried using PgcDemux again on PGC #01 (to see how many black frames i get at the start.)
Now it only has 0-29 (30 frames) as black. which should make up the difference of 12 frames I had.

EDIT: well to my surprise after using pgcDemux i now have 12 less black frames on the start of the video, but the delay is still 0.4 off for episode one just like when I used move only mode in ripit4me.

I have one last idea and that is to take the ac3 audio track that DGIndex demuxed for me from the movie only mode ripit4me, and combine that with pgcdemuxed first title full dvd mode ripit4me m2v video.

will report back shortly.

[manono]

I mentioned earlier doing it by VOB ID in PGCDemux. It's very possible for there to be a delay at the beginning of each episode when they're all in the same PGC. Did you try ticking 'By VOB ID' and then checking for a delay?

You seem to be saying the delay is constant for each episode. Earlier you said (or I thought you said) it got worse with each cell. If you can demux by VOB ID using PGCDemux, you will either be given the delay or can figure it out easily enough. You can also get the episodes at the same time you decrypt while using DVD Decrypter in IFO Mode. Just check the number of chapters corresponding to each episode. Set up a separate folder for each. I read the RipIt4Me log and it did clean out a number of crap cells, but I don't know if that'll fix your problem. I think you should concentrate first on getting the individual episodes into the hard drive to begin with. Once you do that you can use the '[' button in DGIndex on each to go past those first black frames if necessary and then (with any luck) have the episodes back in synch.

[xekon]

Just checked it on the one where I used ripit4me in movie only mode:
(The one where i used ripit4me in full dvd mode has the same delays)

OK, I am going to try extracting by vobID i will let you know how it turns out.

[manono]

And those are the lengths of the various episodes? Sounds like you're making progress. Now, if those delays are accurate you should be able to remove them using DelayCut, or otherwise deal with them without having to figure them out yourself, and you should be good to go.

It also looks to me like there are still a bunch of unremoved cells, but this method of demuxing may be a way around the problem and you won't later have to use the '[' trick in DGIndex.

[xekon]

EDIT:
Still having issues with the audio sync. I spoke too soon earlier because demuxing by Vob ID makes the audio sync off by a much lesser degree, so it is less noticeable. ~100ms instead of 400ms+

I would really like to be able to use the entire PGC title from PGCDemux or decrypt it in a way that I can index the vobs directly using DGIndex, without having the audio delay.

I already know the difference in black frames at the start is 12 frames, and that for episode one a delay of 12 frames got that episode back into sync.

I am wondering what type of encryption/perversion they used to cause this problem.

[manono]

When demuxing you don't really need to check either the celltimes.txt box or the logfile box. Of course, you do need the video, either by checking the video box or the PGC VOB box.

I agree, that is odd about the delay. To try and track down why you don't need to deal with the delay maybe make a PGC VOB in PGCDemux, run it through DGIndex to make a D2V and see if that resulting AC3 audio mentions a delay in the title.

Or maybe you're so tired of messing with this you'd rather get to encoding all those episodes you're planning on doing. Good going!

[xekon]

Originally Posted by manono

It also looks to me like there are still a bunch of unremoved cells

that got me thinking, this is the one I ripped main moviemode in ripit4me, I extracted just VID 01 "by VOB id" and I had both video stream and all audio streams checked:



it only extracted a video stream, there was no audio stream for that Vob id. and the video is Black frames 0-11 (12 frames. exactly the amount the first episode was out of sync by when I used DGIndex directly on the Vobs after using ripit4me on mainmovie mode)

So like you said there is still some VOB ids in there that are probably the root problem I was having.

I am guessing ripit4me was not picking up on these?

Also those 12 frames are doubled up inbetween episodes, so that means there are

12 frames at the start
episode
12 frames
12 frames
episode
12 frames
12 frames
episode
........etc.... all the way to the 6th episode.

can these 12 black frame vob ids be manually removed? and then the IFOs corrected & vobs cleaned up etc?

[manono]

Originally Posted by xekon

Still having issues with the audio sync. I spoke too soon earlier because demuxing by Vob ID makes the audio sync off by a much lesser degree, so it is less noticeable.

So, it's a lesser delay than before? Maybe around -200ms, as shown by those earlier PGCDemux AV Delay screens you posted? -200ms isn't a whole lot, and it's harder to tell delays for anime since the dialog doesn't match the lips anyway since it's all dubbed, and loud sounds are also all dubbed in. I think you should try those delays you showed a few posts up to see if they work for you.

My guess is you don't need to remove those audioless cells. It's possible, yes, and PGCEdit is the tool for that. It's a bit tricky, though.

[xekon]

12 frames is 400ms with honor pulldown flags enabled: (12/(30000/1001))=0.400 or 400ms

I have no explanation for why the audio delay is only ~100-150ms off. My guess is that it has to do with using PGCDemux rather than DGIndexing the vobs directly and then using the audio file the DGIndex demuxes for me. But since I know that 12 frames worth of delay 0.4 fixed the first episode earlier I would really like to try this approach.

I have downloaded PGCEdit, and I am going to do some more reading about how to use it.

Thanks again for all of your help, I feel like I am making some real progress now, can't wait to finally have this resolved.

[Overdrive80]

As I wrote but someone removed my post, the boxes has delay. 12 frames isnt 400ms, 12 frames * 32 ms (1 frame audio ac3) = 384 ms

Are you ckecked the metric between box funimation and toei boxes??? Funimation increase frames, for matching audio and keep synchronized.

If you extract the same episode using PGC, every number frames should be the same in both videos but isnt it.

[manono]

Originally Posted by xekon

12 frames is 400ms with honor pulldown flags enabled: (12/(30000/1001))=0.400 or 400ms

Not to quibble, but the 'real' framerate is 23.976fps and therefore it's closer to half a second. It's only duplicate fields being added to go from 23.976fps to 29.97fps and the length is the same either way.

I have no explanation for why the audio delay is only ~100-150ms off.

It can't be those 00.12 cells since they're not in the VOB IDs. And you're sure you can tell the difference between ~100-150ms and -213ms? I say go with the delays you were given by PGCDemux.

[xekon]

yes I do understand the real freamrate is 24000/1001. and I have noticed that playing it back in AvsP with a .d2v honoring pulldown flags or not, the audio still seems to playback at the same rate. I have noticed that if I use FORCE FILM option in dgindex that the audio is out of sync, I think part of the video prior to the episode is hard telecine. but since I only need audio from these boxes ive just been using the honor pulldown.

I also understand that the amount of audio delay that I use would be the same amount of delayed or cut, regardless of the framerate because as you said the length is the same.

but in trying to figure out the amount of delay to apply, you can trust your ears or calculate it, now if I am playing back the video at a rate of 29.970 and I want to delay the audio by an amount equal to 12 frames at that given frame rate would I not do the math the way that I did it? (12/(30000/1001))=0.400

I understand that if you cut off 400ms from the audio you are cutting off the same amount of audio weather it plays back at 23.976 or 29.970, but I am referring to how you come up with the 400ms figure in the first place.

[Overdrive80]

[xekon]

Originally Posted by Overdrive80

As I wrote but someone removed my post, the boxes has delay. 12 frames isnt 400ms, 12 frames * 32 ms (1 frame audio ac3) = 384 ms

Are you ckecked the metric between box funimation and toei boxes??? Funimation increase frames, for matching audio and keep synchronized.

If you extract the same episode using PGC, every number frames should be the same in both videos but isnt it.

What I have noticed is that the funimation or Toei box has additional frames for the episode opening, sometimes 10 usually 1 , or sometimes they have the same number of frames. BUT the eyecatch in the middle does have a different number of frames.

so the job is not as simple as using one track on the other. you have to get the opening frame # exactly after the previous episode recap and episode title, and then the frame directly before the eyecatch, that makes your first Trim() then you need the frame # directly after the eyecatch up to the end before the next episode preview or credits depending on what you prefer. that is your second Trim(), then you Alignedsplice() these together.

you have to do this for BOTH the english and Japanesse versions then you have to calculate if the number of frames for your trims match in the Funi and Toei boxes.

I am using an excel spreadsheet to keep track of all these frame numbers.(and to do the calculations) The episodes themselves do in-fact have the same number of frames though, with the exception of a couple episodes that need a couple extra frames trimmed from the start on either the funi or toei box.

[xekon]

I am going to give the PGCEdit program that manono recommended a shot. I prefer that method over using Delaycut if I can get it to work. if 12 frames is equal to 384 then thats only 16ms off from my estimate which I could have definitely mistaken.

not sure why I came up with 400ms though if your coming up with 384. I am sure there is some technical reason to it though.(or delay cut is wrong *shrug?*) I think I do recall somebody saying that 1frame ac3 was equal to 32ms, maybe that was you in another thread?

I would be curious to see the amount of ms delaycut would cut if you set it to cut 96 frames

[Overdrive80]

I know. You can adjust video and audio for parts:

video=("x.d2v")
audio=NicAC3Source("x.ac3")

AudioDub(video, audio)

####Try found matching metric between videos, for that frame 2615 would be the same in both videos. And this way for the remaining parts.

	#Opening
	D0=Trim(0,2615)

	#Resume
	D1=trim(2616,4749)

	#Title
	D2=trim(4750,4953)

	#Episode - First part
	D3=trim(4954,16311)
	
	#Eyecatch
	D4=trim(16312,16603)

	#Episode - Second part
	D5=trim(16604,32431)

	#Ending
	D6=trim(32432,34735)

	#Advance
	D7=trim(34736,0)
	
	UnalignedSplice(D0,D1,D2,D3,D4,D5,D6,D7)

I would do of this way

EDIT: In the snapshot, delay cut info of "frame lenght" that is 32 ms, I did not invent that number because stream audio has frames too, but other class.