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

http://i1208.photobucket.com/albums/cc361/xekon/001.png
http://i1208.photobucket.com/albums/cc361/xekon/002.png
http://i1208.photobucket.com/albums/cc361/xekon/003.png
http://i1208.photobucket.com/albums/cc361/xekon/004.png

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]

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.

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.

http://i1208.photobucket.com/albums/cc361/xekon/ep1_zps9d0fcca1.png

http://i1208.photobucket.com/albums/cc361/xekon/ep2_zpsa76f4557.png

http://i1208.photobucket.com/albums/cc361/xekon/ep3_zps329ee81d.png

http://i1208.photobucket.com/albums/cc361/xekon/ep4_zpsfeb686de.png

http://i1208.photobucket.com/albums/cc361/xekon/ep5_zps73d569ce.png

http://i1208.photobucket.com/albums/cc361/xekon/ep6_zpse99bd647.png

[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]

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:

http://i1208.photobucket.com/albums/cc361/xekon/problem_zpscdc8669b.png

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?

http://i1208.photobucket.com/albums/cc361/xekon/vobids_zps66f24222.png

[manono]

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]

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]

http://s12.postimage.org/wjbaeromh/Sin_t_tulo.jpg (http://postimage.org/image/wjbaeromh/)

[xekon]

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.

[xekon]

audio=NicAC3Source("x.d2v")

WAIT! are you messing with me???? does that work? you can use the .d2v as an audio source? I have always just used the .ac3 it demuxed as my audio source!!!

does the .d2v give you indexed audio?

I dont see how that could work especially when there are multiple audio tracks.

[Overdrive80]

Sorry, mistake copy & paste. I fixed it.

[xekon]

you had me going for a minute there lol.

[Overdrive80]

For example, if you opening has 12 frames more than japanese video, you could fix it. This way you should fix dropped/increased frames, and looking for equal metric between videos.

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(12,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 do not know, if they understood the method. I hope so.

Excuse for my english. ¬¬'

[xekon]

hmm the only issue I think UnalignedSplice would left align the audio right? so you would take off 12 frames of audio and 12 frames of video.

AlignedSplice would left align the audio as well but it would buffer or cut the audio at the end of the trim so that the audio stays in sync between trims.

I prefer to just remove all those goofy audioless cells and see if it fixes the audio delay or not when using DGIndex directly on the vobs. it would make things much simpler.

EDIT: I think I know why you suggested this, the audio is out of sync when only working with the FUNI version. at the moment all I am doing is trying to encode the Funi version and it is out of sync.

you probably thought the sync could be from the two not having the same frames, but im not even to the point of putting the Funi music with the TOEI video yet.

[manono]

I have noticed that if I use FORCE FILM option in dgindex that the audio is out of sync
The video length is the same whether using Forced Film or Honor Pulldown Flags. Therefore neither can cause the audio to go out of synch. It's either out of synch for both, and by the same amount, or in synch for both.
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
OK, now I understand. How are you figuring the number of frames anyway? When I'm trying to resynch audio I experiment with delays when playing the video in MediaPlayerClassic-HomeCinema and once I have the amount it's off, remove it using DelayCut. I'm sure he's correct, but I don't worry about that 32ms stuff that Overdrive80 is concerned with. If I don't want to change the audio delay I cut or add video frames, not audio frames. At 23.976fps, each video frame=~42ms.

[xekon]

I figured the delay using the math I posted with excel:
The 0 where it says cell offset, was from back when I was figuring in the cell delays, if I enter a delay in that box it gets added to the listed delay values.
I get my initial delay by listening to the playback.(also have AvsPmod set to launch MediaPlayerClassic-HomeCinema) I get it as close as I can with my ears.
I then scan over a few sections frame by frame in AvsP to see that the audio graph is lining up with the video.
I then play it some more in those areas and listen closely.
once I have found a value that is close I compare it with the values listed in excel, because I assume any audio delay will be a result of x number of frames.

http://i1208.photobucket.com/albums/cc361/xekon/delay_zps7ce63a00.png

In this picture this is the first frame where his mouth is opening and is just starting to talk:
notice the audiograph goes from flatline to spiking. good sync :) This works best in scenes with talking or actions but without music or low volume music, because the music makes the graph go nuts.
http://i1208.photobucket.com/albums/cc361/xekon/graph_zps96692e2d.png

[Overdrive80]

I'm sure he's correct, but I don't worry about that 32ms stuff that Overdrive80 is concerned with. If I don't want to change the audio delay I cut or add video frames, not audio frames. At 23.976fps, each video frame=~42ms.

To use delaycut you arent cutting video frames, only audio frames and maybe its not properly use 42ms as unity for one frame.

1000ms/(24000/1001)=1001000/24000=41.708333333333336 ms for 1 video frame

[Overdrive80]

hmm the only issue I think UnalignedSplice would left align the audio right? so you would take off 12 frames of audio and 12 frames of video.

Yeah, I have posted my script but i dont need cut audio, I should have changed it. My mistake





EDIT: I think I know why you suggested this, the audio is out of sync when only working with the FUNI version. at the moment all I am doing is trying to encode the Funi version and it is out of sync.

you probably thought the sync could be from the two not having the same frames, but im not even to the point of putting the Funi music with the TOEI video yet.
Dont you believe that would be better sync audio directly with toei box's video? If you first fix asyncrony with funimation's video, I think that after you will have problems of sync with toei's video too.

[xekon]

yes I could use the english track with the toei video directly like that. the funi video would be off from the funi audio but then it would line up with the TOEI video.

but if i do my trims so that both the funi video and toei video have identicle number of frames then in the end it would only be a simple matter of muxing the Funi track to the toei video.

This approach I am doing will only work though if I have the Funi audio track and Funi video in sync first.

but I do understand now the method you are describing and it would work that way too.

[xekon]

So I am giving PgcEdit a try with the dvd files that I got from running ripit4me in MovieOnly mode. (anydvd enabled)

as soon as I loaded it into PgcEdit I get this message:
sounds as if it has already found a problem and will fix it for me when I save.

http://i1208.photobucket.com/albums/cc361/xekon/hmm_zps2939d9fc.png

[xekon]

ok after using PgcEdit, VobBlanker, and IfoEdit I think I have found the best way to do what it is I wanted to do.

First I re-ripped the movie. This time I did NOT use DVDDecrypter for angle processesing. I turned that back off.

The reason is because it leaves it multi-angle still, but with one angle blank or unreferenced.
I know this because the copy I ripped earlier when loaded into VobBlanker complained about the additional angle.
I think DvD decrypter Angle procesing is also what left behind some angle cells, because it didnt actually remove them entirely.

so after ripping using ripit4me in movie only mode with Anydvd enabled.

I take a look at it with PGCDemux "by VOB id" shows 63 entries:

http://i1208.photobucket.com/albums/cc361/xekon/movieonly_zps323721b4.png

I then opened that dvd folder into IfoEdit.

From the main menu "Movie Only" select "Strip Streams"

I then check the box "Remove Angles":

http://i1208.photobucket.com/albums/cc361/xekon/ifoedit1_zps67529222.png

then click OK and another Window will Open, here I unchecked all the streams except the audio stream I am interested in:
make sure "Correct IFO tables" is checked.

http://i1208.photobucket.com/albums/cc361/xekon/ifoedit2_zps75639edf.png

Then click "Strip it" and another Window will open, it has a Stream List, this list for this DVD has 63 entries, one entry for every VobId.
That is the same amount of VobIds listed in PGCDemux,
so I looked back and PGCDemux and unchecked all of the VobIDs here that listed in PgcDemux a duration of 00:00:00.12
VobIds: 1,9,10,18,19,27,28,36,37,45,46,54,55

http://i1208.photobucket.com/albums/cc361/xekon/ifoedit3_zps820ed802.png

then click "Strip it" once its done those stupid audioless cells are GONE!

[manono]

Just OK it and then double-click the movie. In the new screen are all the cells and their lengths. Make note of the ones you want to get rid of and then at the bottom of that new screen hit the "Remove Cells" button and take it from there.

What program shows you the video with the waveform? I'd like to try something like that.

Edit: While I was fooling around you continued working. And you pretty much duplicated Doom9's old IFOEdit angle-stripping guide:

http://www.doom9.org/mpg/ifoedit-multiangle.htm

[xekon]

I am using AvsPmod: http://forum.doom9.org/showthread.php?t=153248

with this test.avs script:
the 2 in AudioGraph(2) is the amount of neighboring frames waveform to see.


LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\s9d1m\254.ac3")
V = MPEG2Source("F:\s9d1m\254.d2v")
AudioDub(V, A)
#DelayAudio(-0.213)
ConvertToRGB()
AudioGraph(2)


you can DL audiograph here: http://avisynth.org.ru/docs/english/externalfilters/audiograph.htm

[xekon]

That would be so cool if me pointing out that AudioGraph helps you in some way.

You have certainly helped me a Ton and I definitely appreciate it, I have accomplished a lot more in the last 2 days than I have in the last 3 weeks.

EDIT:
Edit: While I was fooling around you continued working. And you pretty much duplicated Doom9's old IFOEdit angle-stripping guide:

http://www.doom9.org/mpg/ifoedit-multiangle.htm

That is hilarious, well atleast I finally figured it out.

I first searched PGCedit remove cell, that lead me to mostly VobBlanker results. so I thought cool I will use VobBlanker instead, but when I opened it with VobBlanker it complained about the angles, then I though well I know IFOEdit can remove angles, so I tried it and lo and behold I can remove those VobIds right there in IFOedit.

So right now I am really liking IFOedit.

[xekon]

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.

ok, I think I understand what you meant here now. When I extract by Vob id, it is getting just that section, so those 12 frames couldn't possibly cause a problem when demuxing by Vob Id

I have now found a very reliable way of checking the sync, some episodes start with IMMEDIATE sound. This episode for example:

Look to the Far right of the Frame, see that audio graph much active, that should be the first frame:
http://i1208.photobucket.com/albums/cc361/xekon/254a_zps2534b7d2.png

here it is with DelayAudio(-0.165) (PERFECT SYNC):
(this should have been a delay of -213ms)

http://i1208.photobucket.com/albums/cc361/xekon/254b_zps5b67595a.png

Now just to be sure the episode was Indeed supposed to align with that audio I checked several other places where a sharp sound only lasts for a frame or two. and -0.165 is indeed PERFECT.

As I was checking this I noticed the eyecatch in the middle of the episode has 2 scenes (like most do) but the first scene goes completely quiet at the end of the it then audio immediately for the second scene

Directly before the second scene in the eyecatch:

http://i1208.photobucket.com/albums/cc361/xekon/254c_zps2be69ea8.png

The first frame of the second scene in the eyecatch:

http://i1208.photobucket.com/albums/cc361/xekon/254d_zps09373529.png

So why does a delay of -0.165 line up the episode perfectly, but the delay is reported as -213ms?

Let me know if you would like me to check the descrepency on other episodes, now that I know about the eyecatch, it should work perfectly for checking delay on every episode! (I never noticed this before because I was using Trim() to go around the eyecatch)

Also I remembered you saying this:
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.

So I gave that a try and the .ac3 file from the PGC VOB created by PGCDemux demuxed using DGINDEX shows the same -213ms delay: "VTS_01_1 T81 2_0ch 192Kbps DELAY -213ms.ac3"

I dont understand where the discrepancy in the delay could be coming from.... Like you, I figured if PGCDemux reports a delay of -213ms for that Vob ID then that is what it should be.

213-165 = 48ms

I would just like to note that when I removed the Black frame Vob Ids +48ms is the amount of delay I had to apply to this episode when I was working with the entire PGC Title instead of a single Vob Id, by the time I got the last episode it was an amount of roughly +10 frames worth of audio +delay

[Guest]

Suppose you have the video and audio elementary streams with starting times differing by 50ms. Then you mux them. The reported delay will be 0ms when making a project with DGIndex. But when you play it there is the 50ms delay. The point is that the streams may not have been synced when passed to the muxer. I hope I made this fine point clear.

[xekon]

The point is that the streams may not have been synced when passed to the muxer.

I do think I understand this, you mean when the dvd was muxed/authored by Funi. (The Producer)

....audio...... (needs +delay more than reported delay, it starts later when originally muxed)
......video......

so my episode reports a delay of -213, but I have to add a delay of 48ms to that because the audio starts later than the video when they muxed it which would give me -213+48 = -165ms

Do you know of a tool or way to get that information? (the 50ms delay, or whatever it happens to be for a given PGC title or Vob Id)

I am guessing there must be a way to calculate it since the original dvd can play back in a regular dvd player without sync issues.

I would prefer to find the delay information and apply it rather than manually finding the delay by adjusting DelayAudio() per episode.
It just seems it would be the proper way of doing things, and even using DelayAudio() per episode I could be off +/- 1-2ms.

[Guest]

Without a stream sample to analyze, speculation is useless. I tried to explain how the real delay could be different than the reported delay. Another possibility is that something happens in the stream beyond the start, such as an edit. It would still play in sync in the original because the PTS timestamps are present. But when you demux the streams, you lose the timestamps. The last time I tried to explain all this it ended in acrimony. Hopefully we don't go the same route. :)

[xekon]

It would still play in sync in the original because the PTS timestamps are present. But when you demux the streams, you lose the timestamps.

Nope that pretty much sums it up for me. hmmm.....

So if you were me, and you wanted your audio perfectly synced what would be your next step? tools used, information inspected, etc.

What tools can I use to check if the real delay is indeed different than the reported delay or if it is just that something is happening in the stream beyond the start like the edit you are mentioning.

I am not afraid of any advanced tools, and I love to learn new things. I have been working on figuring out this sync issue for weeks, no way i'm about to give up now :)

[Guest]

So if you were me, and you wanted your audio perfectly synced what would be your next step? tools used, information inspected, etc. I would post an unprocessed source sample together with instructions for how to duplicate the issue, so as to allow experts to properly analyze what is happening. The first thing to establish is whether there are PTS discontinuities in the stream. I have a personal tool for that but it's not something I am able to release publicly right now.

[manono]

The last time I tried to explain all this it ended in acrimony. Hopefully we don't go the same route. :)
Hehe, this fellow has more on the ball than the other guy, and isn't as stubborn as a mule.

What I don't understand is how the audiograph proves anything at all. Are you showing that when it's in the middle of the screen and you have the first instance of the mouth opening it's evidence of synch? Even with anime and dubbed audio, as opposed to live action stuff?

[xekon]

I agree Manono that syncing the audio to the lips is not going to be completely reliable. because they will be off at certain places because it is a dub. (one of the reasons I had trouble verifying sync when we though we had this figured out)

but the last pictures I posted, that show the sharp change in sound for both the first frame of the episode and at the very center of the eyecatch where it changes from one scene to the next is a very good indication of the sync. +/- 1-3ms -165ms or -166ms lines these scenes up Perfectly and the audio when playing it back matches so perfect that I cannot see a problem. (also when working with the entire PGC title the audio becomes more out of sync each episode, which could be somehow related to this problem)

I can post all of the tools I used and the steps I took to get to where I am now to duplicate the issue, that is not a problem at all.

What I don't understand is how the audiograph proves anything at all. Are you showing that when it's in the middle of the screen and you have the first instance of the mouth opening it's evidence of synch? Even with anime and dubbed audio, as opposed to live action stuff?

oh I dont think I understood what you were asking at first. Yes the center of the green line(audio graph) indicates the current frame you are viewing. (the line is brighter green for the current frame)

The darker green to the sides of the brighter green is the neighboring frames, you pass the amount of neighboring frames worth of audio graph you want to be viewable to the function. AudioGraph(3) indicates that I want the current frame bright green in the center, with 3 frames worth of audio to the left and 3 frames worth of audio to the right, of the current frame as well.

[xekon]

neuron2, I have sent you a PM containing Links to the sample files.
You wanted them before decryption or any processing whatsoever right?
If you needed something else please let me know.

I included All of the DVD Files except the 1GB .VOBs, for those I only included the first 1GB .VOB

steps to reproduce audio sync issue:

1. AnyDVD HD 7.1.2.0 installed and enabled, default settings.

2. Set DVD Decrypter to the following settings: http://adubvideo.net/how-to/anydvd-dvd-decrypter
In addition to this guide, set these settings on the file mode tab:
http://i1208.photobucket.com/albums/cc361/xekon/dsettings_zpsc1a9b9aa.png

3. With AnyDVD in system tray and active/enabled, insert DVD

4. Load RipIt4Me, click Wizard Mode, Select 'Movie only' click next, click create PSL, click Rip DVD,
DVD Decrypter should Launch and notify you the protected sectors list imported successfully! click ok.
select your destination and click the Decrypt Button
once completed DVD Decrypter will close, and the wizard will be on Step 3B: Ifo cleanup.
Step 3B: Ifo cleanup: All four boxes checked and click Do it!.
Step 4: Cleanup VOBs: Both boxes checked and click Cleanup VOBs.
once VOB Cleanup is done click Done and close RipIt4Me

5. Load PgcDemux, Load the input IFO created from the previous step, select an output folder.
check the boxes Demux video stream, and demux all audio streams.
click 'by VOB id' for the Mode, Select the First VID in the drop down menu that is over 10 minutes. (First episode)
click Process, goto your output folder and rename the VideoFile.m2v and AudioFile_81.ac3 to 001.m2v and 001.ac3

6. Load DGIndex, set Video > Field Operation > "Force Film" (DGIndex reports that it is pure FILM, so I used that this time.)
Open 001.m2v and goto File -> Save Project, which will generate a .d2v

7. Load AvsPmod, use the following test.avs:


LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\s9d1\001.ac3")
V = MPEG2Source("F:\s9d1\001.d2v")
AudioDub(V, A)
DelayAudio(-0.141)
ConvertToRGB()
AudioGraph(3)


with "Force Film" the delay should be DelayAudio(-0.141)
goto Frame 13398/13399 and you will see the sharp change in the audiograph with the scene.
also at Frame 1543 he clicks the trigger, you can see the difference in the audiograph, the click sound lasts for less than one Frame worth of audio.
then at Frame 1556 it goes from a Black Frame to an Explosion on 1557

[Guest]

Thanks for the well-documented process and links. It will take a while to download them and get to grips.

[xekon]

Thank you so much for the help, I appreciate it and I am very curious to see what you find out. (hoping it is something I will be able to solve after you have identified the issue. This show has 9 seasons, 291 episodes.) I had no idea when I started this project that it could be this difficult.

I generally use a program called JDownloader to download from the free file share sites, you can load as many files as you need and it will download them for you, if the site has a capcha it will pass that prompt to you to type it as well. I do not believe rapidshare or mediafire uses capchas and last I checked mediafire had very good DL speeds, but its been a while since I used a free file host for anything.

[Guest]

Somebody else said this but I also say, hey it's anime. There is no consistent definable sync that is constant. You choose one offset and some things are in sync, you try another and other parts are in sync.

Anyway, I got stuck at your step 3, because I don't have a DVD. Please make the process real simple and exclude all unnecessary tools.

[xekon]

step 3 can be worked around (Just tested it myself with the very same folders I sent you)

download img tool classic: http://www.afterdawn.com/software/cd_dvd/iso_tools/imgtool_classic.cfm
(standalone exe, when it asks for settings on first launch leave everything unchecked and click save.)

after extracting the files you downloaded from me structure it like this:
F:\sample\VIDEO_TS\VTS_12_1.VOB

click source folder in imgtool classic. load the sample folder, then click the save disc for the output file location. then click the Image button.

This will give you a .iso File.

Then install virtual clone drive (its free from the creators of ANYDVD) : http://www.slysoft.com/en/download.html

then you can mount the .ISO created by ImgTool Classic, and continue with step 3.

I wish I could have thought of this, then I could have done these steps for you, very sorry :(
EDIT: (I just noticed that after you turn it into a .ISO the file size becomes 8GB, so the way I sent you the files may actually be the best way.)

The sync is off in some episodes by as much as 150ms, and by correcting this sound effects line up with their actions.
In most anime actions such as punches or explosions and even music in a new scene will line up perfectly. The only thing that will not always line up correctly is lip movement with the voices because the lip movement was originally drawn for another language, and Funimation does do a pretty good job of lining up the voices with the lips. (This is why I chose scenechanges and clicks/explosions/punches usually to line things up)

[xekon]

Neat I learned something today, These DVDs are using seamless joints it seems.

Learned a ton reading over this: http://forum.doom9.org/showthread.php?p=739144#post739144

[Guest]

How did you rip the VOB you gave me? I hope you ripped a single angle.

Assuming that, I see that your stream has irregular pulldown. So if you apply force film you will create variable audio sync throughout the stream. This may be what is happening. Can you try things with Honor Pulldown?

Sorry but I won't download all those tools. You should be able to demonstrate the issue simply with the one VOB you gave me and DGIndex/DGDecode.

[xekon]

(The vob I gave you I just copy and pasted from the DVD with zero processing...)

My original method that I have been working with up until yesterday was with Honor Pulldown. That is why you can see interlacing on my picture of the eycatch on page 2. I did notice the amount of delayaudio I had to use was different with Honor Pulldown than it was with Force Film(-0.165 vs -0.141), and I was wondering why that was, thanks for that explanation. The reported delay to use for the episode is -0.213 but that throws the entire episode out of sync

I must have misunderstood, I thought when you asked for the steps that I took that you wanted to all of the steps I took from step A to step Z.
(In the previous steps I outlined, for my process I was letting PGCDemux strip the angle.)

Please let me know if the following would be ok:
(and I'll do it over, the problem is that I do not know exactly what you need because you did say unprocessed.)

My steps:
1. pull 1st .VOB directly from DVD (without decrypting, not using anydvd, dvddecrypter, or ripit4me)

2. run that .VOB through IfoEdit to remove all but the first angle.

3. Upload that .VOB to you.

Then once you download the files the only steps to follow from my original guide:

6. Load DGIndex, set Video > Field Operation > "Honor Pulldown Flags"
Open VTS_12_1.VOB and goto File -> Save Project, which will generate a .d2v

7. Load AvsPmod, use the following test.avs:


LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\s9d1\001.ac3")
V = MPEG2Source("F:\s9d1\001.d2v")
AudioDub(V, A)
DelayAudio(-0.165)
ConvertToRGB()
AudioGraph(3)

[Guest]

Perfect, thanks. I can work on it this evening.

Can you please give me the frame numbers for the events you point to again but for honor pulldown? They will be different from the numbers for forced film.

[xekon]

yes thats why I deleted those comments from the original guide. I needed to double check the frame #'s

I will get to work on it right now :) thanks again. Also did mediafire DL at a good rate or would you prefer rapidshare?

[Guest]

Mediafire worked great for me. Don't ever point me to rapidshare!

I can't work on it until this evening so you have a good 6 hours to collect new frame numbers for the critical sync points.

[xekon]

If I use DGIndex on the .VOB directly the amount of delay to get it back into sync will be different than the amount of delay to get it back into sync if I use PGCDemux to demux by Vob ID.

This is because there are audioless cells before every episode.

would you like the me to use PGCDemux to demux by VOB ID and give you that delay + Frame #s for sound events.

or would you like me to use DGIndex on the .VOB directly and adjust the delay and Frame #s to line up?

Also if you prefer I can remove the audioless cells but then the amount need to line everything up is a positive delay, roughly +0.048 for the first episode, and then by the time you get to the 6th episode on the disc its around 0.334

or another option since you will only be working with the first episode I could use the right arrow a couple times then use the '[' button to cut off several black frames at the very beginning in DGIndex and report those Frame #s plus delay.

[Guest]

or another option since you will only be working with the first episode I could use the right arrow a couple times then use the '[' button to cut off several black frames at the very beginning in DGIndex and report those Frame #s plus delay. Yes, do that. Please report the number of > hits before the [. Then report the frame numbers for the key events as seen in AvsPmod or VirtualDub.

[xekon]

neuron2, I am still working on uploading the sample files, I will send a PM once they have finished uploading.

1. Load DGIndex, set Video > Field Operation > "Honor Pulldown Flags"
Open VTS_12_1.VOB

click the "[" key here:

http://i1208.photobucket.com/albums/cc361/xekon/dga_zpsb4241048.png

2. Load AvsPmod, use the following test.avs:


LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\samp\VTS_12_1 T81 2_0ch 192Kbps DELAY -213ms.ac3")
V = MPEG2Source("F:\samp\VTS_12_1.d2v")
AudioDub(V, A)
DelayAudio(-0.165)
ConvertToRGB()
AudioGraph(6)


goto Frame 16747/16748 and you will see the sharp change in the audiograph with the scene.
also at Frame 1928 he clicks the trigger, you can see the difference in the audiograph
also at Frame 0 with DelayAudio(-0.165) the first frame is lined up with the audio,
if you comment out DelayAudio(-0.165) you will see that the audio is off by roughly 5 frames.
and that a delay of -213ms would lose some of the audio that belongs with the first couple frames of the episode.

Now something else I noticed, if you click ">" only 5 times from the very start of the .VOB and save project, the .ac3 file that DGIndex demuxes reports a delay of -165ms. I found this interesting because thats the delay that works with the episode. but if you try and use this .d2v with the .ac3, the audio is not actually a delay of -165ms. but I did find that -165ms value interesting... like maybe its not a coincidence, but maybe it is.

I tried doing this with the second episode (click ">" only 5 times from the very start of the .VOB), and DGIndex reports a delay of -165ms for the second episode too, but the second episode has a different delay than the first episode, so its either just a coincidence or I just cant figure out the significance.

[Guest]

Whoa! What sample files? I already downloaded one set.

Using the VOB I have already downloaded, referring to the timestamps dump I generated with DGIndex, one sees that you need to skip 4 GOPs at the start. So, hit > 4 times and then [. Then save project. When I do that I get AC3 files with 0 delay reported. I then make this script:

vid=mpeg2source("VTS_12_1.d2v")
aud=nicac3source("VTS_12_1 T82 1_0ch 96Kbps DELAY 0ms.ac3")
audiodub(vid,aud)

Sync looks fine.

Please don't make me do big downloads repeatedly. Let's work with this one I have if possible.

It appears that the only problem here is the starting GOPs without audio.

[xekon]

Oh ok, I was going to reupload so I could strip the angle for you. Can you see if sync Looks good on T81 instead of T82?

I am going to checkout T82 now to see if I see the same difference that you do.

[Guest]

You have multiangles in the VOB you gave me? I'll wait for your clarification before proceeding. I will have to get the new sample if the original had multiple angles.

Anyway, it's all about correctly skipping the leading GOPs without audio. Use the timestamps dump to determine how many to skip. If you skip too many, then you get to an open GOP and will have a nonzero delay.

[xekon]

Yes, I gave you a multiangle VOB because i'm still a noob, and when you said you wanted the VOB before any processing I took that literally and did nothing with the VOB before sending it to you.

(The new one that I was working on uploading has only had one single processing done, and that was using IfoEdit to strip the angle.)

I also get a 0ms reported delay when I use the ">" four times before saving.

but the audio delay that it takes to fix it if I do that is DelayAudio(1.283)

http://i1208.photobucket.com/albums/cc361/xekon/fixa_zps00413717.png

next frame:
http://i1208.photobucket.com/albums/cc361/xekon/fixb_zpsd3732bfa.png

[xekon]

vid=mpeg2source("VTS_12_1.d2v")
aud=nicac3source("VTS_12_1 T82 1_0ch 96Kbps DELAY 0ms.ac3")
audiodub(vid,aud)


Edit: It looked like Track 82 was lining up great, because the audio graph was in sync, but it is actually waaaaaay out of sync, and was lining up with something else, once I played it back and listed to it, it was very obvious. For a minute there it looked like Track 82 was syncing up better than track 81.

(The track I am wanting to use is Track 81.)

[Guest]

Can you please answer my question? Is the VOB you gave me multiangle? I have to know before I can do anything else.

[xekon]

very sorry, Yes it is multiangle. The part that is multiangle is the first part of the episode where it says the name of the episode.

[Guest]

OK, no problem. Can you please provide a stream ripped with a single angle? My idea is to have a common starting point eliminating any unnecessary variables.

[xekon]

Yes I have it uploading now. It is 1GB like the last, and my connection is only Docsis 2.0 so it will probably be about an hour before I have it all finished uploading.

I really wish they would upgrade the cable service in my area, the next town over where my aunt lives has Docsis 3.0 and it is sooooooo much faster.

[Guest]

You know what they say, patience is a virtue. And it gives me some time to sip a little beverage while contemplating the idiocy of modern physics.

This is a cool thread because it is exposing some of the intricacies of AV sync in anime. Even how to define AV sync in anime raises interesting philosophical questions.

[xekon]

Okay, the one hour was a guess on my part by how long it took to upload the first .part file. I then stopped because I wasnt sure if you needed me to upload the rest.

This time I loaded all remaining 5 files for upload and it is telling me a total of 5 hours, so if you have anything else to be doing please do not wait up for me.

hate my crappy internet lol.

[xekon]

You have PM for the new Links, files just finished uploading.

[Guest]

OK, I have loaded the VOB, hit > four times, then [ and save project, with honor pulldown flags. I have this script:

v=mpeg2source("VTS_12_1.d2v")
a=nicac3source("VTS_12_1 T80 3_2ch 448Kbps DELAY 0ms.ac3",2)
audiodub(v,a)

Sync looks great. Please advise.

[xekon]

ok let me try With Track80. (although the track I am wanting to use is Track 81.)

If Track 80 is in sync and Track 81 is not, what does that mean?

[Guest]

I checked T81 and it was fine too.

Please point me to any issues you see by frame number.

[xekon]

ok with track 81, if you playback this section:

Frame 18363 to 18578

where the old man is talking to Gohan, a couple words worth of voices come out of his mouth before his lips even begin to move, and then after the old man is done talking, his lips are still flapping for about a couple words worth.

then gohan goes "uhhhhnnn" like how did he know what I was thinking. This is supposed to happen with gohans face on the screen, but it actually happens before it has switched from showing the old man to gohan.

but if I use DelayAudio(1.283) then everything is in alignment like it should be.

(If all of this lining up for you and not me, I cant think of anything we could be using differently, I am using the same sample files that I uploaded)

I am using Media Player Classic Home Cinema to play back it back, and I have combined community codec pack installed on default settings.

LoadPlugin("F:\AviSynth\plugins\audgraph.dll")
LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
LoadPlugin("F:\AviSynth\plugins\NicAudio.dll")
A = NicAC3Source("F:\samp\VTS_12_1 T81 2_0ch 192Kbps DELAY 0ms.ac3")
V = MPEG2Source("F:\samp\VTS_12_1.d2v")
AudioDub(V, A)
DelayAudio(1.283)
ConvertToRGB()
AudioGraph(6)

[Guest]

Sorry I am not going to get involved in arguing about lip sync for dubbed audio speech. I looked at some other clear AV sync events and they lined up fine. If you like I can point them out.

Here's one in the section you mentioned, look at 18378 transitioning to 18379. Just as the mouth moves the audio arrives in the center of the audio graph.

If there are other sections where this is not the case, it just underlines what I said earlier about some sections being "in sync" and others not. So which is the "correct" offset?

Edit: We must have some basic difference because the scene shifts away from the man at 18508, but you talk about it up until frame 18578. You should NOT apply the DelayAudio(). Why are you doing that??? You really think that the audio is off by 1.28 seconds???

Are you using the same process and script as I have? Please use VirtualDub to open the script and view frame numbers. Obviously if you use DirectShow codecs for playback you are going to get incorrect results.

[xekon]

The audio is sooooooo far off that the problem is obvious. If I pop in the original DVD into my DVD player then this problem does not happen.

were you able to get the audiograph to line up in the center?

I completely understand if you tell me that this issue is not happening for you at all, and that you are done trying to help. In fact if everything is perfect for you then I probably need to think about switching media players or computers and try and figure out what the variable is between our two setups.

please do not just conclude with not going to get involved, I just need a simple answer of weather or not you are seeing the same problem that I am, then atleast I will have a little confirmation of what I need to look into next. a delay of 1.283 is Wild when the delay should have been 0ms, were talking about a huge difference in sync here.

http://i1208.photobucket.com/albums/cc361/xekon/fixa_zps00413717.png

next frame:
http://i1208.photobucket.com/albums/cc361/xekon/fixb_zpsd3732bfa.png

[xekon]

Edit: We must have some basic difference because the scene shifts away from the man at 18508, but you talk about it up until frame 18578. You should NOT apply the DelayAudio(). Why are you doing that??? You really think that the audio is off by 1.28 seconds???

yes, and my frame numbers are different, i think maybe you noticed something, one sec posting pics

edit: here are three sequential frames: this is the transition from the old man to gohan that i was referring to, does this happen at the same frame numbers for you?

one:
http://i1208.photobucket.com/albums/cc361/xekon/one_zps0d0c87c9.png

two:
http://i1208.photobucket.com/albums/cc361/xekon/two_zpsa6f21c17.png

three:
http://i1208.photobucket.com/albums/cc361/xekon/three_zps900f5958.png

EDIT: trying virtualdub now, I honestly have not used it before may take me a second to figure it out if there are any large differences.

[Guest]

You still have the DelayAudio() call in there. Get rid of it!

EDIT: The scene shifts away at 18508 for me but not for you. Are you sure you have Honor Pulldown? This is our problem and we need to get to the bottom of that first. Please post your D2V file so I can compare them and find out why we have this difference.

[xekon]

you asked if I really think 1.28 seconds is the delay, and yes I do. I have been testing with DelayAudio() commented out and with it there.

When I use the 1.28 second delay the entire episode lines up great.

At this very moment I am working on opening it in VirtualDub, and I am going to have delayaudio() removed, and take new screenshots.

I am very curious to see if my screenshot looks different from your screenshot under the same circumstances.

Please let me know if I missed any questions, I read it over twice, and I am sorry for my unorganized responses at times. I will read things over more thoroughly before posting to make sure I answer any and all points before replying.

[Guest]

Please post the D2V file, as I asked. Thank you.

We have to have our video frame numbers lining up before even thinking about audio.

[xekon]

ah I missed that, thank you, uploading now. Also when DGIndex says it noticed a field transition problem. would you like me to have clicked yes or no?

right now I am uploading both incase it matters.

edit: just sent PM with DL link. I also zipped it with the Full path included so you can see how I had them arranged on my hard drive.

F:\samp\VTS_12_1.d2v
F:\samp\VTS_12_1 T81 2_0ch 192Kbps DELAY 0ms.ac3
F:\samp\VTS_12_1.VOB

[Guest]

I do not get the field order prompt. I looked at the D2V you mailed me and it appears you have not skipped the first 4 GOPs as I described.

Again:

Open the VOB. Hit > four times. Hit [. Then save project with Honor Pulldown.

Is that exactly what you did?

[xekon]

Yes originally that is what I did, however I just recreated these files because I was unsure if I clicked yes to correct field order prompt or not.

One second I am doing it again, very sorry, my brain just has not had the affects of the coffee yet or something.

OK I just deleted my old one, new one is in your PM, and it is the exact same one I will use. (you are correct that with four presses it does not ask to fix the field order prompt.)

New link PM to you.

edit: I got virtualdub and I am using the new .d2v that I just generated and sent to you (deleted my old one.) about to check some frames and then post screenshots.

[Guest]

Ok, thanks. I suggest that you really study the timestamp dump and understand how it tells you the right number of GOPs to skip. I'll be happy to explain it if it is not obvious.

I'll look at the new D2V but I don't expect any surprises.

[Guest]

Our D2Vs agree now so I expect you to confirm my results any second now. :)

BTW, the field order transition is a result of not cutting off the first bad GOPs.

[xekon]

So here is what happened, I have been using sooo many tools and soo many different methods and orders to the point of getting flustered and missing steps that I thought I had done myself.

What I had done was click the ">" four times and then save project without setting the stop. "[" on my last attempt. which caused the delay to be 1.23

but I had audio files that had the " DELAY 0ms.ac3" in the filename, which means I got really mixed up at some point and did it right the first time, but then did it wrong the second time, and then worked with those files which gave me the delay of 1.23

You Sir are correct, the first episode is lining up correctly, the center eyecatch does not line up as perfectly as I thought it would, but that may be the way Funimation did it.

I will do this with the remaining 5 episodes on the disc to see if they all line up this good or if it gets worse per episode.

I believe they should all be good like this episode though! I really hope so that would be great.

[Guest]

It's an important lesson to learn. When debugging or analyzing, always strive to reduce things to the smallest number of variables possible. Easy to say, sometimes hard to do.

I'll look at the eyecatch again on T81. I seem to recall it was within a frame of being correct on T80. Who knows if they timed it right on the original. That's why anime sync is so challenging and your thread is so important, despite some bumps along the way.

[xekon]

Yes very much an important lesson, one that I seem to learn over and over :( I always tend to get ahead of myself or mix things up the point of chaos.

here is the eyecatch for track 81 (I marked with purple how I expected it to line up.):
I expected the part I circled to line up with the Vertical Line that I drew. (but like I said this is a much smaller amount of delay than 1.23 maybe funimation did this on the original mux. I am going to try other episodes and take screenshots of their eyecatch too, that way I can look for differences in alignment.)

http://i1208.photobucket.com/albums/cc361/xekon/align_zps7e65af26.png

[Guest]

Here's my eyecatch on T81. The audio starts exactly at the scene change.

You see it's like I said, some parts in sync, some not. It's apparently the nature of anime dubbing. Chopping the bad GOPs gets you the "real" delay encoded in the stream, but it may not be really real. Now I'm confusing myself :)

...

[xekon]

That is how mine looks at that particular frame as well. but in that scene they may have meant for there to be a 2 frame delay before the audio started for the eyecatch,

but in the screenshot I posted you have some audio that happens before the scene change happens, (where it goes from showing one car to showing a different car)

This to me seemed to show an issue more, however maybe Funimation made this error when they dubbed it.

Earlier in my tests when I was manually lining up episodes the amount of delay that was need to correct the episode varied per episode. The first episode had the least amount of problem, the delay needed was only 48ms while later episodes were off by as much as 170ms.

I am working on checking the other episodes now.

[Guest]

My point is who knows what they intended, or if they erred in implementing their intentions?

Going down to this single frame sync analysis for anime I think is guaranteed to drive you bonkers.

Play it at normal speed and if everything looks fine why worry?

You could study every sync event and try to minimize the number of imputed misalignments, but is it really worth it when played at normal speed, nothing really appears wrong? This is the philosophical issue I alluded too earlier.

In working with the other episodes, be sure to chop the correct number of GOPs. I assume you know how to get that number from the timestamps dump, as you have not asked me to explain that. Just look for how many leading GOPs you have without audio.

[xekon]

I do think I understand now how to chop the correct number of GOPs. Thank you :)

[Guest]

You're welcome. I have to thank you too for bringing that audiograph() function to my notice. I wasn't aware of it and how useful it is.

[xekon]

I have used Blender & Sony Vegas and other non linear video editors before for other projects, and really like being able to see the waveform.

When I started having sync issue with this project I immediately started looking for a way to see the waveform with avisynth :)

[xekon]

Alright so that episode was about 2 frames off. Another one I am doing now is 5 frames off. I am guessing since you could not find a problem with the stream that it is indeed something that was off when it was originally muxed by the producer.

I can see the difference, and with only 1-2 frames off its almost impossible to tell, but with 5 frames off it gets even more noticeable.

Since I cannot figure out what is happening exactly my best idea is to find the alignment of each episode by looking at the center of the eyecatch on every episode and make it so the eyecatch lines up the same for all of them. Then I should be within 3ms for the sync, which should be impossible to notice while watching it. a lot better than 5 frames off anyway :)

I was just really hoping for a way to get the delay information without adjusting manually per episode, but if the problem happened directly from the producer than it is very possible that there is no way of doing that. I have been reading through some forums I found by searching google for a similar issue and found somebody talking about the sync being off on the remastered blu ray version of a DBZ movie but the audio sync was perfect in the DVD version, so that alone tells me that they do make mistakes when they produce these (can I have their job, talk about quality control problem)

[Guest]

Sounds like you've got the bases well covered. I haven't seen your new stream so I'll not comment further.

[xekon]

It seems there production method must have changed as they produced these, the small cell toward the opening of the episode that gives the Name of the episode was film for season 9 but on the older series it is not reported as FILM for that cell. Also the eyecatch is a different scene, it shows little gohan getting on gokus shoulders, and the music is different, it does not have that nice sharp cut off, even though there is sound that I could align per episode to look the same, once I had one to go off of.

I will post more pictures after doing 20+ episodes. Then I will know which episodes show it the most and in the most obvious ways to visually and audibly confirm. (It will probably be a week or so, I want to do a bunch of them the way I described as it will probably end up being the only way to do it.)

[Guest]

You haven't actually demonstrated any audio sync problem yet for a properly handled stream, so you're really talking to yourself now. I will still suggest to just use the encoded AV sync and thereby save a lot of time and agonizing.

[xekon]

Well, that is what I was trying to show with this picture:

http://i1208.photobucket.com/albums/cc361/xekon/align_zps7e65af26.png

Music happens on frames where music does not belong, a delay of 0.048 corrects this. But because the delay is only 48ms the episode look OK to most people because it is such a small difference weather you fix it or not.

I know the difference is small, I actually got about half way through the 291 episodes before I started noticing that some of the episodes did not feel like they were in sync when watching them.

So I started investigating. As I correct them all manually I will store the delay required to fix each episode and list the worse ones after I am done.

[Corpsecreate]

whoaaa so much to read, how did I not see this thread ages ago. I'll pm u xekon with my scripts once I turn my PC on. Also, the episode that will give u the most trouble is episode 65 right before the eyecatch. You'll see what I mean.

[xekon]

hey, welcome to the thread, I will have to check that out.

some discussion about the sync issue with the dvds that I am working with, the problem is in the source, and there is nothing i can do about it.
http://www.kanzenshuu.com/forum/viewtopic.php?f=7&t=16542

The original boradcast or season sets may not have had this issue, I cannot confirm.

THANKS TO EVERYONE FOR ALL YOUR HELP! Funimations used seperate tapes for the music, sound effects, and voices and this is why if you line up the music, then voices/sound effects will be off or vice versa.

skipping the gops with the ">" key and setting it "[" and then saving per episode from the .VOB files

mux and then go :) sorry if I was a little trouble, I could just tell on most episodes that there was a sync issue (more on some episodes than others), but atleast now I know why. I will just try my best to ignore the errors because there is literally nothing that can be done about it.

Edit: I have found that most episodes have a small overall audio alignment issue in one direction in addition to the sync discrepancy between the music & sound effects.
The Faulconer track used different music alltogether, so I have not been worrying about trying to correct sync based on music, only on sound effects and voice.
I have noticed with the discrepancy I have fixed in the audio alignment that when I adjust the delay to correct the alignment for soundeffects that both the lips and music are coming back into alignment.
I think the issue discussed on kanzenshuu about the sync issue between music and effect is only relevant to the tracks that have the original japanese music.
On those tracks I would prefer sound effect sync over music sync, you decide. but the track I am working on at the moment is the Faulconer track anyway.

[xekon]

I see what your talking about when I checked episode 65. The problem with 65 is not that it is more out of sync(well it is but not for the reason you might think), the actual issue is that there was a transfer error on the Japanese version where there were about 20-30 extra duplicate frames, when Funimation did the english version they cut these frames out, so If you are using the Funimation english track with the R2 DragonBox video, the solution I am going to use is 3 extra trims to cut the frames from the R2 Dragonbox Video that are not present in the Funimation english video.

I do think there are some episodes that can look a lot more natural and play better if the delay is tweeked some, you basically just have to pick what is most important though, sound effects lining up or the voices.

[Corpsecreate]

They aren't duplicate frames. The scene of gohan trying to get up goes longer on the Dragon Box than it does on the orange bricks, no frames are duplicates. For some reason, Funimation removed some of this scene (my guess is because this particular scene has one frame of interlaced footage).

My solution to this problem is not the same as yours because I am also adding the japanese audio to my files which will cause that to desync (unless I cut it). Instead, I loop the english audio for 17 frames, the particular loop point I used makes it hard to notice that it was ever edited.

[xekon]

Ahh thats what it was, and that's a pretty good idea for that!

[xekon]

OK, so I figured something else out today. The points at which the audio goes out of alignment on the earlier seasons is the points where DGIndex Film % changes. usually one just after the eyecatch and then another about half way through the second half of the episode.

I am trying to figure out if DGIndex saves a log when you press "F5" I would like to get more detailed information. Like exactly which Frame # that percent changes. I assume this FILM % changes every time DGIndex sees a spot where it would need to insert or drop frames in order to "Force Film".

My idea was to look at the precise frame # where the film % changes and exactly how many frame #s were dropped or inserted, and then my hope is that the audio offset can be calculated from that.

this is how I have been fixing the earlier seasons manually:

A = NicAC3Source("F:\dbz\eng\001.ac3")
V = MPEG2Source("F:\dbz\eng\001.d2v")
f1=AudioDub(V, A).delayAudio(-0.242).trim(0,13166)
f2=AudioDub(V, A).delayAudio(-0.238).trim(13467,21692)
f3=AudioDub(V, A).delayAudio(-0.190).trim(21693,30000)
AlignedSplice(f1,f2,f3)

f1 is before eyecatch 100% FILM
f2 is after eyecatch 99.99%FILM
f3 is about half way through the remaining episode after the eyecatch 99.97% FILM

[Guest]

Film percent is averaged over time from the start of the project and so it cannot give you reliable frame-accurate information.

Film percent can change without inserting or dropping frames, as when pure 3:2 pulldown changes from soft to hard and back.

You have fallen down a rabbit hole with your sync obsession, in my view. Why don't you trust the authors? Is there some solid evidence that the coded delays are wrong by some objective criterion? What is your criterion for correctness?

[xekon]

What is your criterion for correctness?
My ears/eyes, there is a noticeable sync issue that is resolved when I adjust the delay. I have found several sound effects that happen 2-5 frames later than they are supposed to.


I could tell there was a noticeable audio sync issue ever since I started this project, but it was difficult to tell exactly what was going on.

So at first I thought it had to do with my decryption/demuxing process, so I started this thread.

After talking with you, I know now the correct way to handle the streams, and if I want to correct the sync issue it will be up to me to do it manually because the issue exists on the original dvds.

So I have been going about it manually. I will simply play the episode, and when it gets noticeable that it is out of sync then I do my best to figure out where that started and correct it.

So today as I was working on episodes. I would save a .d2v file for the next episode, and usually when its saving I watch the FILM% as its saving.

well as I fixed the sync on an episode today I noticed that the spots that it was out of sync matched the spots where DGIndex reported a change in FILM%.

AND just before writing this reply I noticed something else. Those spots where the FILM % changes are where it transitions from one CELL to the next.

However, when it transitions from Cell 1 to Cell 2 the film percent stays 100% (which makes since because I did not have to adjust the sync for the full first half of the episode until after the eyecatch), then from cell 2 to cell 3 the Film % changes, then again from cell 3 to cell 4.

Now I manually lined up this episode by ear before even noticing the coincidence of the FILM% changes being at those exact spots, then when investigating a couple minutes ago I discovered it was at cell transitions.

EDIT: The episode I sent you earlier was from the last season of the series, they did not have audio sync issues the same way, this seems to be something else entirely. on the one I sent you I applied a delay to the entire episode to correct it. On the earlier season episodes the amount of delay required changes drastically between cell 3 and 4

[xekon]

Ok so I took this one step further, using what you showed me earlier in this thread.

I used the ">" button, but I went all the way to 75% through the episode to the start of cell 4 and set the stop "["

When I do this, and use the delay reported in the outputed .ac3 file then that cell lines up the same way it does for the one where I did the entire episode as a single .m2v: "f3=AudioDub(V, A).delayAudio(-0.190).trim(21693,30000)"

So I am no expert and I am just guessing, but could the audio have ended before the video on cell 3? and when the audio for cell 4 got demuxed it was out of alignment with the video? because once I get to cell 4 I require a more positive delay value.

EDIT: If this is the case I will just use DGIndex per cell like this. so that each cell lines up the way it is supposed to, and then alignsplice() all 4 cells together.

when I make my .d2v files I will need to go beyond the cell by a couple extra ">" press or after using the reported delay I would have some silence at the end of each cell.

[xekon]

Well this is great. I will have a lot less work to do now :)

Is there already any guides on using DGIndex per cell and then Trim() and Alignsplice() them together like I will be doing.

If not I would be happy to write one. Im sure most DVDs dont have problems quite like these ones do. but some do I'm sure.

Edit: yep, was an open GOP, skipped a step in my decryption process that caused the issue, woops. So now I am back to just correcting the sync for the overall episode :) Ive got the first couple seasons audiodelay corrections done and I have encoded 42/291 episodes :)

[Guest]

So I am no expert and I am just guessing, but could the audio have ended before the video on cell 3? and when the audio for cell 4 got demuxed it was out of alignment with the video? It's possible yes, but it's also possible that you have an open GOP there. I always ask for stream samples.