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.