Jump to content

Song gets out of sync in 3.10.12


Mark Birsching
 Share

Recommended Posts

I recently updated to 3.10.12 and ran into a problem I had not seen before.  If I play song all the way through, it works fine and the audio matches the video. But, when working on part of a song and the Play Range is set to only play the part of the screen showing, then the audio gets off.  It's a audio file I've used for years and is set for the correct bits per second (128).  This is the first time it's happened on this audio file.  If I play from the beginning, then it's fine again. 

 

Since I'm working on the final seconds of the song, it's annoying to have to replay the entire sequence just to check everything is in sync. It worked fine in 3.8.x and earlier, so is there something I need to change or a new option to check?  Computer is plenty fast. 

 

Thoughts from anyone?

 

Thanks!

 

Mark

 

Link to comment
Share on other sites

Ditto with mine....

I was sequencing just fine for particular parts for the past month (with 3.10.8) then I did an update to 3.10.12 (yesterday)now the play visible screen or anything but play full sequence is off on the audio track...?

Link to comment
Share on other sites

Open the sequence and change the state of 'Use Internal Media'.  If it's off, turn it on or vice versa.  Does the problem go away?

Thanks Mike, That seems to have corrected my sync problem. I have been using this song for a long time now and knew it was CBR at 128, but I still ran it through Audacity again but that didn't fix it. I turned my "Use Internal Media" on, and that corrected it.

Link to comment
Share on other sites

When we (LOR) say things like CBR 128K RULES, that is really a gross over-simplification that typically fixes 99.9% of the problems out there.  The reason is that by re-encoding the file in question (via LAME), we get rid of the 'weirdness' that may be screwing up WMP.

 

Now, most of the time that weirdness has to do with VBR coding.  Sometimes however, it has more to do with how the data was encoded - even with CBR.  The MP3 standard doesn't really specify bit-for-bit what an encoding should look like.  So if you run the same PCM data through 2 different MP3 encoders, you will most likely get 2 different files out the back end.  They may sound the same, but the actual bits are going to be different.

 

...And that is where a problem sometimes comes in.  Audio decoders can just 'do their best' and/or 'throw away' stuff that isn't correct.  Usually without impacting the sound quality.  Unfortunately, programs like LOR S3 can't do that.  We rely on WMP to give us accurate (to the ms) timings.  When it starts throwing away incorrectly coded information, the timing and the audio get out of sync.

 

The same thing can happen on the decoding side of things.  The decoder is responsible for taking the MP3 data and producing a PCM bitstream from it.  To do that, it is not just looking at the current time, but also before and after the time in question.  2 different decoders could look at an identical MP3 file and produce 2 completely different PCM streams.  Again, the decoder could look at this current 'chunk-o-stuff', decode it into something invalid, and throw it away.

 

So every-once-in-a-while we see a problem with an MP3 that by all rights should be PERFECT:  It's CBR.  It's 128K.  It was encoded with LAME.  Yet, it still goes south.  Welcome to the world of dealing with media. :(  

 

That's one of the reasons we've changed media handling in 3.9/3.10.  We will continue to work on it in 3.11 and future releases.

Link to comment
Share on other sites

Why not simply use linear wave PCM files? Disk space is cheap and converting to wave also not a problem. Most of us run the songs through some program anyway before using them in a show and all LOR users could save a lot of headache by going linear. I know upconverting from MP3 does not restore the lost quality but to simply eliminate this as a possible source for trouble saves time for other things....

Link to comment
Share on other sites

Open the sequence and change the state of 'Use Internal Media'.  If it's off, turn it on or vice versa.  Does the problem go away?

Mike:

 

I re-ran the file through Audacity (a newer version) and the problem seems to have gone away.  If it comes back, I'll try using the internal media option.

 

Thanks for your help!

Link to comment
Share on other sites

Why not simply use linear wave PCM files? Disk space is cheap and converting to wave also not a problem. Most of us run the songs through some program anyway before using them in a show and all LOR users could save a lot of headache by going linear. I know upconverting from MP3 does not restore the lost quality but to simply eliminate this as a possible source for trouble saves time for other things....

 

Good question.  Here's the answer:  Did that.  Got the T-Shirt.  Returned it for our money back.

 

The original idea was to create PCM WAV files right off the bat.  3.10.0 in fact does use PCM WAV internally, and assumes that ALL media can be converted to WAV,for the exact reasons you describe.  Here's the problem -- WMP can NOT change the playback speed of WAV files properly.  Grrrrrr.....  Then we discovered that due to encoding issues (like the ones above) we were not able to reliably create WAV all the time.   Double Grrrrr......

 

As it turns out, there was no one answer to all of our media problems.  Starting with 3.10.8, we create 2 different internal files - one of which is PCM WAV.  The system will then look and attempt to choose the best of all 3 files created, Original, PCM, or Internal for the task at hand.  The 'Use Internal Media' controls a lot of how that happens.  When that option is OFF, the only choice the system has is the original file.  

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...