Page MenuHome

Audio Synch Bad After Opening Good 2.49 file in 2.5 29272 (poor sound quality)
Closed, ResolvedPublic


I just started synching IPO to music, via keyframing. I started in 2.49 and I wanted to go up to 2.5 for final render. But when I open my 2.49 file in 2.5 29272. I discover that the import of the IPO data is no longer synched with my music tracks?

I checked fps, it is set to 25fps in both 2.49 and 2.5. The audio files are 11Khz uncompressed waves. Then length of the audio is approximately 2:40. I am using 3 audio tracks with various instruments separated, instead of a single stereo track mix.

Also, the music itself sounds of poorer quality than the same tracks being played by 2.49 on Windows Xp64.

Blender 2.5.2 29272
Window XP64 3GB
nVidia 9500
RealTek Audio Device

Download the beautiful world file and extract. This will make a folder structure as well. This contains the BLEND file and two of the three music tracks in a folder called "sources". The second download contains the final music track. Place the final track in the "sources" folder as well.

Open the attached file in 2.49 and press play. Wait for the drums to kick in and observe the synchronization between the empties and the sound track. Kick drum and Snare drum are featured in layer-1. Layer 11 contains other synchronizes elements as well.

Now open the same file in 2.5 and observe the results. I hear a poor quality sound and the animation no longer lines up correctly.

I am not sure what is making the bug, the sound system or the import of the IPO data. But something is certainly off.



Event Timeline

I have to upload each additional WAV file as a separate comment.

And here is the final WAV file. Unzip the two additional WAV files into the "sources" folder created by the beautiful_world_1c ZIP file.

For me this is neither synced in 2.49b nor in 2.5. Maybe the problem actually arises due to 2.49? Moreover I guess you haven't enabled AV-sync in 2.5?

In my opinion the Quality is in 2.49b worse as I can here an annoying high tone all the time that most likely comes from bad quality upsampling.

What audio backend are you using in 2.5? What build (own? graphicall? what build system?)?

I just pulled down build 30205 and this bug still exists.
The audio backend is the default of OpenAL. It defaults to 32 bit float and I tried 16 bit signed as well.

The high pitch "whine" you hear is actually part of the song intro. I am guessing, maybe you are hearing some true problem. But the song does start with a synthesizer hold note that is kind of rising.

I tried the different synch options and they mode no difference.

I also get actual crashing. Just open the 2.49 file in 2.5 and click play. Blender will crash.

You will have to take my word that on my Windows XP64 machine that the 2.49 file is synched. I have not tested this 2.49 file on Linux or Max OSX so I can not verify the operation in 2.49 on those OS's.

If the display seems confusing to you, just turn on only layer 1. That layer has the kick drum and the snare drum only. They are certainly synchronized to the music on my machine. Which is a Intel DUO 2.5Ghz with 3GB ram. nVidia 9500 card. Realtek audio.

Thanks for taking a look at the file. I hope it helps track down bugs.

Ok I asked the windows plattform maintainer and we still didn't get to a real agreement, at least the crash we cannot reproduce and without a backtrace there's nothing we can do anyway.

I decided to do a testfile that should show syncing better and to clear that syncing problem, which is attached, please try it. For me it works perfectly in 2.49b as well as 2.5 with any sync method. The wav file is 11k just to make sure that's not the problem.

Quality vice there's nothing I can do as the resampling is backend dependend. The best tip I can give you here is to NOT use 11k audio, especialy not in the second millenium, so grab your favourite audio editing software like audacity and upsample it to a quality of your liking to 44.1k.

Thanks for the test file. I tried it and it works as you describe.

But it is hardly a real world test. I chose 11Khz because Blender can not play 44Khz correctly and certainly not three tracks at a time @ 44Khz as my example BLEND file is using. I am not hung up on 11Khz by any means, but it was the only thing that worked in BLENDER.

By the way, my system runs Ableton Live fine with many more than 3 tracks of 44Khz audio along with effects without any drop out problems at all.

Try this!

Create a much longer wave file (or just use mine), this way you are not tempted to just embed it in the Blend. Break your tracks out into three separate instruments. Make a 3 minute song with three tracks. One for Kick, one for snare and one for hi hat. Then bring them in and play them from the hard drive. Set your end frame around 4,000 or more to match your audio.

Your test is good, it shows that Blender can play three seconds of audio from RAM. But I don't think it is as good a test as my three minute three track song playing from the hard drive which many people will want to do. At least two tracks, voice over and music right? Where I work, three tracks are common place. Typically they are music, voice over and sound effects.

PS: What is a back trace? When Blender crashes it takes the console with it on Windows.

First of all: 44k works perfectly here in 2.49b as well as 2.5, even with 3 ogg streams that have to be decoded while playing.

Second: Your 2.49 file is loading the wavs into RAM as well, 2.5 doesn't by default, but you can enable caching there for each sound to do it there too. So if you open that file in 2.5 the sound is not played from RAM, but you're true, if it's packed into the blend file it gets decoded from RAM but that doesn't really affect the test anyway.

But as you wanted I created a testfile now with 3 3 minute wav files with 44k this time and put them into blender as you did (so in 2.49 they are played from RAM!), everything still works pretty fine and correct here.

PS: if you want that we check the crash you have to tell us exactly, which build you used.

Actually, for a backtrace you need 1) a debug build of Blender and 2) a debugger. For windows if you build with MSVC I recommend windbg as your tool, although the Visual Studio built-in debugger should work too (if you have that - if not, then windbg).

Ok yet another test with your files this time:

If I'm right the right sphere should go up exactly when the guitar and co start playing.

The sphere goes up exactly at frame 118, the animation is running at 25 fps. According to audacity where I've opened the wav file, the sound wave starts to get nonzero at 4.36381 seconds and the sequencer strips start at frame 0.

So calculation wise your animation is off by: 118 - 4.36381 * 25 = 8.90475 frames, I guess those 9 frames are exactly what you're off in 2.5?

In conclusion I would say that's a 2.49 bug for you although 2.49 works fine here for me.

Ok, as you haven't responded now for some days I consider this as yeah, being a bug, but in 2.49 rather than 2.5 so it's fixed here. In case you find an actual bug in 2.5 we can always reopen the bug or write a new bug report.


Joerg Mueller (nexyon) closed this task as Resolved.Jul 14 2010, 3:00 PM

I consider this lame that you closed this bug. It is not a bug in 2.49. As I have stated, it works fine on my Windows machine in 2.49. I am sorry if the music confuses you. It really is synched in 2.49 and fails in 2.5.

But I guess you are under pressure to close open bugs. Isn't that why Matt Ebb quit? He stated the bug count was atronomical.

Did you try what I suggested?

I'm not sure why you think I did not respond. It is you who did not take it to the next level and conduct a better test that lasts more than 3 seconds. The problem is in the HD version of wave processing , obviously. Conduct a longer 3 minute test.

What a let down. 2.5 will never be done with this kind of bug processing.

Don't worry, someone else will try to do the same thing I did an the bug will be re-reported. Thanks for taking the shortcut to closing bug, I see they are not really worth reporting after all.

Are you kidding? You call me lame, although you cannot read? I not only provided the testfile with 3 3 minute strips that are loaded the same way as in your 2.49 file, I also gave a quite scientfic proof that this is a 2.49 bug.

Btw. "It is not a bug in 2.49. ... It really is synched in 2.49 and fails in 2.5." sounds like "It's not a bug in Internet Explorer 6. ... It really displays correct in Internet Explorer 6 and fails in Firefox 3.". Excellent proof...

If you're unsatisfied with the development, why don't you start developing yourself? I think you should rethink your behaviour and how you talk to someone that spends his spare time into developing software that YOU use and pay nothing for!

Ok, so guys, the two of you - don't start fighting it out in here. If you must, settle your scores privately.

With the test file it all goes as supposed, yet, as I told nexYon on IRC, the animation in Atomics' file seems to start too late in 2.5 (at least to my ears and eyes - about half a beat).

So, Atomic, does shifting the strips fix your particalur case? (And please, no flaming/ranting anymore from either of you). Also, does this erroneous behaviour appear consistently with other .blend files?