Having a problem with audio sync in x264 conversions.

[andythebeagle]

It seems that any given ap that uses x264 gives me a sync problem which then needs to be run thru AVIDemux to fix. Problem with that, it looks like it messes with my HandBrake job. I have tried several different programs to see if it was just HandBrake, however it seems that it is the x264 codex that creates the issue.

How can this be fixed? Is it something I'm overlooking??

Any answers will be greatly appreciated

Media info attached

Thanx in advance, Al Moon (aka: andythebeagle)

[jagabo]

It doesn't look like that h.264 source should be giving you problems. How is the audio out of sync? By a constant amount all the way through? Starts out in sync but gets more and more out of sync as time goes by? Starts in sync then suddenly goes out at some point?

[andythebeagle]

It doesn't look like that h.264 source should be giving you problems. How is the audio out of sync? By a constant amount all the way through? Starts out in sync but gets more and more out of sync as time goes by? Starts in sync then suddenly goes out at some point?

Thanx for the quick reply. The reason I think it is the x264 encoding that creates the sync issue is regardless of the GUI being used, if I use x264, the video and audio are out of sync. If I encode in any other format, the audio and video are in sync. I have tried every container, format and encoding technique I have and the result is the same each time. Here is a list.

Any MS container, AVI, DivX, FLV, Matroska, MP4, MPEG, Ogg, Quicktime or WebM. As long as I do not format the video in x264 and use another method of encoding, there is no problem. If I introduce x264 into the mix, then the audio is out of sync. It appears the audio is out of sync through out the encode by a constant factor, not progressive. I see this because AVIDemux will put it in sync. The problem I have is the re-doing of every encode just to sync the 2 streams, however doing them in AVIDemux does another encode after x264 has already been done. I would really like to do the job just once. Reworking everything is getting tedious. If I do not re-do, Youtube upload will sometimes reject the video because of sync issues, which makes the effort just "not worth it" because of the time involved.

If YT had not specified h264, I'd just do everything in Flash and not worry about it. Putting x264 into the container just plainly sucks.

So, your statement : "It doesn't look like that h.264 source should be giving you problems." Just does not represent my experience. Sorry. Now if you can show me exactly why you say those words, I will consider my experience invalid.

Included is an example. It is a Flip the Frog cartoon "Soup Song". The Delay relative to video : 67ms.

Double check it with MediaInfo.

Look in my files to see video. http://files.videohelp.com/

Hope it works.

andythebeagle

[andythebeagle]

Sorry, I'm tired and frustrated. Spend entirely too much time on this stuff.

[hello_hello]

I replied to your post in the other thread but I guess you can ignore that now.

There's no reason why x264 encoding should cause audio sync problems as such. I..... and millions of other people..... use the x264 encoder regularly without the same problem, which pretty much eliminates x264 as being the cause. Similarly, lots of people use Handbrake without having the same issue.

So to be honest, you need to try to find out why this problem is fairly unique to you. If you say running the files through AVIDemux fixes it, whether it re-encodes or not, if the output is h264 then once again it kind of eliminates the encoder as being the cause.

MediaInfo showing an audio delay relative to the video isn't out of the ordinary, in fact often that delay is required. If the original file uses a delay for the audio then generally programs will re-encode the original audio "as-is" and use the same delay when adding the encoded audio to the output file. It's possible your player is ignoring that delay, however.....

I'm a little bit lost when it comes to suggesting a possible explanation for why you only experience the problem when using the x264 encoder. Unfortunately the link to your files isn't working but it might pay to try again to provide a sample. For lack of a better explanation it seems like it's probably a problem with playing the encoded files, not with the actual encoding. Likewise though, I can't explain why YouTube might reject your encodes due to sync issues.... I can't even explain how YouTube would know if the audio and video are in sync.

I don't use AVIDemux so I'm not sure what it does, but there's a chance that instead of using a delay value for the audio, it adds the equivalent amount in silence to the beginning of the audio when re-encoding it, so an audio delay in the output file is not required.

Have you tested the encoded files using more than one player? Which player do you use? What the MediaInfo link in your first post the source file or the output file?

All I can say is I agree with jagabo, there's no reason why h264 encoding should cause audio sync problems. I understand it doesn't represent your own experience, but I can state with a lot of confidence your experience isn't the norm. Maybe if you could post a short sample from the original video along with your encoded version of that sample for comparison? And if the encoded version has sync issues, maybe you could run it through AVIDemux and upload the "fixed" version too?

[jagabo]

One common cause of sync problems when converting video is a variable frame rate in the source. The encoding program often assumes constant frame rate and you end up with audio that gets out of sync. It wasn't clear to me if the MediaInfo report you provided in the first post was of the source or a file you made from it. I guessed it was the source. If so, it uses constant frame rate so VFR isn't an issue.

It also uses constant bitrate MP3 audio so that shouldn't be a problem (VBR audio sometimes causes sync problems). But oddly, the MediaInfo report also shows a maximum bitrate of 4000. None of my CBR MP3 encodings show a maximum bitrate. Maybe that's a hint.

Since your sync problem is constant throughout you can just remux with a different delay value. Use negative delays to advance the audio (if that's the problem).

[andythebeagle]

Thank you both for stating what should be obvious if I had been paying attention or knew what I was doing. The idea of the bit rate/frame rate never occurred to me. Even when I hear or read things, that doesn't mean I get it.

Do I then do encodes in VFR as a standard practice?? I can see that it might just eliminate a problem by following input frame rate regardless. I never really paid any attention. I'll give it a run tonight.

The thing about Youtube is their upload page includes software that monitors your upload for everything from quality to copy rights. That's a good thing and they have a editor which can take care of a lot of things, However, no sync. Most of their stuff uses a filter collection that will not change the upload, but will effect the view. If you re-download your own video, it comes back just how you sent it. If you sent crap, you receive crap. Nice thing about that?? Keeps ya honest. However, if someone puts up the same video from a public domain site, you can down load the better vid and submit it instead. A lot of work for the average homeowner.

AVIDemux, like so many pieces of video software, has a lot of goodies on board. That and AVISynth, VDubMod and even MeGUI are all good, depending on what you want to do. For me, there is all to much to know about all of them to allow me to know very much. So I just use them for what I can do right now, or am willing to figure out. Being so new to this has made it a very interesting time, albeit overwhelming. Never even thought about this stuff until last September. Then it just ran me down in the middle of the night when I wasn't looking.

More often than not, I'm dazed and confused more than any thing else.
Rest of them time?? Surprised.

[hello_hello]

Most video is constant frame rate. I'm not exactly sure which containers can and can't hold variable frame rate video. MKV definitely can, I think AVI has to be CFR but I'd have to research MP4. Some programs only output constant frame rate video (as AVISynth assumes CFR). There's a few ways around it when encoding using an AVISynth based program but the problem wouldn't be x264 exclusive. If you encode VFR video and it effects the audio sync it'll do so regardless of the video encoder used.

If you select the VFR option in Handbrake it should encode VFR video correctly. If you select the CFR option it should convert it to CFR.
Anyway, without samples of the original and encoded video and answers to the questions asked, I think it's fairly unlikely you'll find anyone can offer a definitive reason for why it's happening.

[jagabo]

I recommend you avoid VFR encoding. It rarely saves you more than a few percent in file size (CRF encoding) or quality (bitrate encoding). In exchange you get incompatibility issues with some players and video that's much harder to edit in the future. Using VRF encoding with a VFR source won't help matters. If the program doesn't understand VFR sources it still won't handle the source correctly.

MKV and MP4 support VFR. AVI does not support VFR. But there are a few programs that don't understand Null frames ("repeat last frame") that some encoders use in AVI files.

[andythebeagle]

I may have found the problem with the sync. Trying to do things in an mp4 or mpeg container with x264 and any AAC codex is where the issue seems to be. Mp3, FAAC and Libav is where a problem lies. It's in the combination with the x264. When I put the entire thing in a MKV container with Mp3 (LAME) codex, it works just fine. Therefore, the package is MKV x264 mp3 (LAME). Good package, good compression, good sound and great sync.

Hope this might answer some thing for anyone else who has a sync problem.

[hello_hello]

What player are you using to view the encoded files to confirm the audio sync problem? Is it present regardless of the player used?

I ask because you specifically mentioned the problem occurs with MP4 but not MKV. I discovered a while back that MPC and/or MPC-HC completely ignore any audio delay in MP4s. They respect the delay if the container is MKV (I think the same applies to using the Haali splitter rather then the internal MPC-HC MP4 splitter).

The upshot of it is, if you re-encode a file which uses a delay for the audio, most/many conversion programs will re-encode the audio "as-is", then mux it into the output MP4/MKV while applying the same audio delay. Theoretically that should be fine.... the audio sync will be exactly as it was, but in the case of MPC-HC and MP4, the delay isn't used when playing the encoded file.

VLC seems to respect the delay, but I've no idea what other hardware/software players do.... I never use MP4 myself. Some MP4 muxers (well YAMB at least) even let you specify a delay for the audio when muxing but don't actually apply the specified delay to the output file.

Mind you none of the above should be specific to any particular combination of x264 encoded video and audio..... it should apply to MP4 in general.... and of course would only be relevant if the original video actually used a delay for the audio. There's also a chance some conversion software will insert silence into the beginning of the audio when converting it so the output file doesn't need to use any audio delay as the original did (and maybe do it for some audio types but not others). I guess theoretically that'd be the better way to do it as then there's no issue with the player respecting the delay (or not) but then again theoretically it'd be even better if all players respected the delay.

Anyway..... MediaInfo should tell you if the original file used an audio delay, it'll tell you if the output file uses the same audio delay, and if I'm on the right track that might help find the cause of the MP4 audio sync problem. Does it happen every single time when the output is MP4?

[andythebeagle]

I work with public domain cartoon shorts doing both restorative work, "remastering" when possible and general conversion and reformatting for upload to several video hosting sites.

Almost every video available has been handled so much that the compression has done damage. However, all of the works, when produced, were synched by the production studio and so far every one has no delay in the original. I have many hundreds.

The problem made itself known by the YT uploader. It tests for several things that must be done prior to upload. When I was notified on an upload, when new to YT, that the video was out of sync, I had no idea what they were talking about. That was back in Sept. Since then I've been taking a crash course in video editing and formatting. Somethings I never thought I'd ever be involved in. I've even developed a critical eye for the quality of a video in determining if it's worth the effort to edit and reformat.

With all the videos being in sync when starting and then being out of sync after format, I needed to look at what was happening during the process. I still don't know how these things actually work, but can see the results. What I need for a 7 to 10 minute short from the 1930s is for the av to be in sync. If Youtube says so, then it has to be.

That's my story and I stickin' to it. (for now)

[andythebeagle]

I ask because you specifically mentioned the problem occurs with MP4 but not MKV. I discovered a while back that MPC and/or MPC-HC completely ignore any audio delay in MP4s. They respect the delay if the container is MKV (I think the same applies to using the Haali splitter rather then the internal MPC-HC MP4 splitter).

VLC seems to respect the delay, but I've no idea what other hardware/software players do.... I never use MP4 myself. Some MP4 muxers (well YAMB at least) even let you specify a delay for the audio when muxing but don't actually apply the specified delay to the output file.


When first starting in re formatting, I did not use x264 codec. Never even knew anything about it. x264 is what YT decided they wanted and in complying with their request, I got into some induced nightmares. Sync being a big one and quality being the other. I had a steep learning curve and being self taught, stumbled around in the dark for a bit.

VLC is my player of choice due to its ability to handle most of what you throw its way. I use it for everything. I don't know if it's best or not, it just works for me. I've got MPC but would need to spend some time to figure out all it can do.

So far, this crash course has been an almost 24/7 endeavor. I'm getting tired and just seeing the MKV format give me a good result, I'm reasonably happy.

Sure, more will be understood in the future, but for now, it works.

[hello_hello]

The MPC-HC not obeying the delay in MP4's issue is no doubt caused by MPC-HC's internal MP4 splitter. If I remember correctly if you use the Haali splitter is ignores MP4 delay in the same way, whereas LAV Filters obeys it (I think, it's been a while since I went through this).

I don't know much about MP4s and I don't care much about them either so I've forgotten any other details regarding the problem and it's not codec specific.

I have no idea how YouTube would know if the audio is in sync with the video you'd have to physically watch/listen to every upload. I've never uploaded anything to YouTube. The current plan to die almost completey free of social networking participation is still looking good.

[El Heggunte]

For the curious:

https://forum.videohelp.com/threads/345598-MP4-file-out-of-sync-in-VLC-not-in-MPC-HC

[andythebeagle]

Thanx, makes for a good read, and I never paid any attention until YT uploader pointed it out. Did some random checking and found that every one of my vids done with HandBrake using Mp4 or mpeg whatever were all off. That was according to MediaInfo. So, that meant that the YT uploader was correct. Ran them thru AVIDemux several different ways and passthru wouldn't work on them. All had to be re encoded with AVIDemux to make them right. It started buggin' me so I spent some time tryin' diff combos. End result? MKV x264 AC3 (lame) worked every time so I didn't ask any more questions. So that's what I'm using now. Really doesn't matter to me which container I use, as long as it holds the contents in place w/o spillin' things all over the information highway. Thing is, the more lookin' I did, the more I found that this problem has been around for some time in one form or another, with a lot of people talking about it but no actual fixes.

[manono]

I work with public domain cartoon shorts doing both restorative work, "remastering" when possible and general conversion and reformatting for upload to several video hosting sites.

I think your audio synch problems are the least of your worries. In that color Betty Boop cartoon, the blacks are crushed and the whites badly blown out. In addition, in every second there are three duplicate frames and what looks to be two missing frames (maybe, hard to tell). They've been converted from film to PAL and maybe your sources were already like that, and also look overfiltered. And maybe not and it can be done properly. It also looks to me like they were badly deinterlaced. I don't know how you've 'remastered' these things, but there's room for lots of improvement. A ten-second untouched sample from the 'source' might be helpful

If Youtube says so, then it has to be.

Nonsense. I get that message on every upload and none are out of synch. I don't use Handbrake, but when uploaded they're in synch, and they're still in synch when being played on YouTube. As hello_hello wondered, how can YouTube know if anything is out of synch? The answer is that they don't. They may very well be out of synch, but the clue isn't from the YouTube message.

[andythebeagle]

[/QUOTE]
I think your audio synch problems are the least of your worries. In that color Betty Boop cartoon, the blacks are crushed and the whites badly blown out. In addition, in every second there are three duplicate frames and what looks to be two missing frames (maybe, hard to tell). They've been converted from film to PAL and maybe your sources were already like that, and also look overfiltered. And maybe not and it can be done properly. It also looks to me like they were badly deinterlaced. I don't know how you've 'remastered' these things, but there's room for lots of improvement. A ten-second untouched sample from the 'source' might be helpful
[/QUOTE]Nonsense. I get that message on every upload and none are out of synch. I don't use Handbrake, but when uploaded they're in synch, and they're still in synch when being played on YouTube. As hello_hello wondered, how can YouTube know if anything is out of synch? The answer is that they don't. They may very well be out of synch, but the clue isn't from the YouTube message.[/QUOTE]

I can only give you the info I'm given. I'm just a messenger on this Youtube stuff. Please don't shoot me.

I haven't had enough experience with this stuff to have the critical eye for problems with a video. I'm in the process of "self instruction" which can truly suck at times. Relying on a person who doesn't know what they are talking about for detailed information is problematic, at best. My biggest effort has been learning conversion and re formatting so they can be used. My "remaster" comment was in quotes and still is. What I'm trying to figure out is how to do that either by re-drawing or thru editing/conversion/filtering. It will probably be the most difficult. Hopefully, I'll be able to learn thru experience how to be a good judge of problems with a video.

The Betty Boop toon was like that when I got it. Most of the vids I have are from old hard drives I was given. There are probably some 2000 toons. I think some may have been taken from VHS. Others seem to have come from either downloading from Internet Archives or DVD. A lot of duplicates. A good share of the B&W look like the ink bled all over the frames. Most are really in rather shaky condition due to one issue or another. So far, it seems that some of them can be filtered out, but I really don't understand just how to use the filters yet. Seems that will take some class room time here in town at our local community college. They have some courses there in video work. I haven't checked them out to see how deeply they go into it. I see that the toon I sent along has some issues with the loop filtering, deblocking, as they ended up being overly soft instead of having crisp edges like drawings should have. Now that I seriously study the vid, I can see flashes and occasional streaking. Not a good thing, and I haven't a clue just what that means. Problem is, I've got some vision issues with cataracts that sometimes interferes.

>>>>>In that color Betty Boop cartoon, the blacks are crushed and the whites badly blown out>>>
Just what do you mean??

If you could give me an idea of what to do, I will buy you dinner the next time we meet. Hope you like hamburgers or hot dogs. Coffee??

Any guidance will be deeply appreciated. Even as to what program would be best to use, what format they should be in and how to set up the filtering.

I thank you from the bottom of my black pitted heart. andythebeagle thanks you too. He's getting tired of laying on my lap and getting a head ache from watching me and the mess I create. Just glad I have the choice to delete bad stuff.

[hello_hello]

>>>>>In that color Betty Boop cartoon, the blacks are crushed and the whites badly blown out>>>
Just what do you mean??

Luminance levels fall within a certain range of values. If you alter luminance in some way and the usual range of values is exceeded, the effect can be for dark greys to become black or for whites to be "clipped" (for want of a better word). That sort of thing.

It may be that your source videos aren't good quality and the sample you posted wasn't the result of anything you did. I've seen DVDs in the past which were pretty terrible, and I'm even certain I've seen DVDs which were mastered using the wrong range of levels.... The PAL DVDs of Battlestar Galactica come to mind. There's a couple of episodes from season three which look washed out. Even the opening titles look different. Space is dark grey, not black.

Anyway, normally you'd re-encode video "as-is" and not need to think about levels. What comes out is the same as what went in. The other stuff manono mentioned... missing frames, bad de-interlacing, over-filtering of some sort etc..... that can all happen when re-encoding, or you could be re-encoding video which had already been badly re-encoded in the first place and there's not much you can do to fix it. Sometimes encoding GUIs with automatic settings for that sort of thing can get it wrong and make a bit of a mess. Hence the suggestion to post a short sample of the source video.

I see that the toon I sent along has some issues with the loop filtering, deblocking, as they ended up being overly soft instead of having crisp edges like drawings should have.

Are you using Handbrake's de-noising filter? I don't use Handbrake myself so I don't know a lot about it (what noise filtering it uses), but noise filtering is generally some sort of compromise between removing noise and blurring the picture a little. If you're using denoising, chances are the stronger the denoising the more potential for blurring there is.

[manono]

If you could give me an idea of what to do,

A ten-second untouched sample from the 'source' might be helpful.

A YouTube video is next to useless. We need samples from as close to the source as you have. Maybe you created some of the problems yourself inadvertently, maybe not.

[andythebeagle]

I think this is the original. Found I've several copies of this. Too cluttered.

[manono]

When someone sends me stuff as bad as that I refuse to work on it. The bad blacks and whites can be fixed, most of it. The duplicate and missing frames can't, not by me anyway.

Unless you have a better source, I'd not work at it at all. I wouldn't think this is the only remaining copy of this short. The guy that butchered it in the first place had a better source to use.

But your source is very bad to begin with. You didn't mess it up any more.

[andythebeagle]

I took a long look at all of the source videos I have for this one and all are worse that the one I did here. I found that I have 20 some copies of this. Most were on old hard drives I was given. I really gotta clean this mess up. I had the suspicion that constant re formatting and compression would ruin them. You're right in saying the first original had to be good. Once you take the same one and distribute it all around over and over, you're not left with much. These videos have a terrible pedigree. There are very few if any original film stock left and even those are suffering from the deterioration of celluloid rot.

[hello_hello]

I had the suspicion that constant re formatting and compression would ruin them. You're right in saying the first original had to be good. Once you take the same one and distribute it all around over and over, you're not left with much. These videos have a terrible pedigree. There are very few if any original film stock left and even those are suffering from the deterioration of celluloid rot.

You should be able to take an encoded video and copy it from drive to drive etc from now until the end of time and the quality won't change. It's only the process of re-encoding it which can make a mess.
The original video itself (DVD or wherever it came from) may have been perfect, and someone made a mess of it when re-encoding it, and that's the copy you're now working with. Or maybe the DVD quality itself was horrible to begin with. Who knows....

[jagabo]

Maybe something better here:

http://archive.org/details/bb_poor_cinderella
http://archive.org/details/Betty_Boop_Poor_Cinderella_1934