Timing shift

[Gilrock]

Using 160 CBR is what worked on the file I had trouble with.  I think there was still a little jump at the start but after the jump the audio was aligned with the waveform.  I'm pretty sure the MAC will probably run better than Windows because the real issue with the underlying problem is not in our code its the fact that our audio library uses the default audio player on the machine which for PC is Windows Media Player.  It doesn't appear to be able to start at exact locations for compressed MP3's and that's why using constant bit rate usually helps.  A better player would decode the packet up to the proper millisecond location to begin playback.  That's why it works if you start from the beginning.  But a lot of folks sequenced songs this past year successfully.

[DMJPixel]

Just tried same process on Win10 PC with Xlights v4.3.02; original mp3 plays with no skip issue.  Imported into Audacity and exported out as a 160 CBR.  Go to around the 8 minute mark and within half second of playing it skips about a half second - can see it better slowed down to 1/4 speed as previously indicated.  Gilrock explanation makes sense and not at all debating any points - just was helping out to show if it was reproduced on a different PC.
Dave

[rcowan]

Thanks Dave. I really appreciate you taking the time to do this.

So here is my takeaway from all of this. The original MP3 works fine. On the surface that tells me that there is not a problem with xLights. As it successfully played the original file without skipping. So, that leads me to something that Audacity or more specifically the MP3 encoder (LAME) is doing to the file that is then causing an issue inside of xLights. While Gil's explanation has some merit, I would expect then for it to happen at all times. I've tried several different applications to re-encode the MP3 file and so far nothing has seemed to work. It sounds like you have no issues with your Mac but I don't have one sitting around so that is not an option for me. However, I am currently setting up a VM with Linux to see if that makes a difference. At first I'll just try re-encoding the files inside of Linux and then using them with my Windows xLights. If I still have an issue then I'll try compiling xLights into Linux and give that a go. Either way, at this point I don't think there is a bug in xLights. It's just some issue with the encoding, the default player or a combination of both.

At any rate, thank you again for your efforts.

And thank you Gil for taking the time to consider this issue and offer some possibilities. I really appreciate what you and the other developers have done with this product and the support you give to the users.

[Gilrock]

There's been talk of us trying to replace using libmpg123 with libavcodec which would hopefully eliminate this issue and allow us to support other file formats and video.  I'm just not sure of the magnitude of work involved to get that done.

[Ebuechner]

After not seeing a reply for several weeks I stopped looking at this forum. I checked in today and was happy and grateful to see that some people have put in effort on this problem. I see that the new version once it's released will be a major rework. With the changes that are going to be made is it a possibility that this problem may be corrected? And I thank the people who put time into this

[Gilrock]

No the audio library is not part of what we've been working on.

[lorajoslyn]

I'll just chime in, and say I have seen this on several of my songs as well.  My songs are all less than 3 minutes, but seeing this in several of the songs from last year and now.   I also changed to all different rates (128,160, 192 etc) all CBR, but no luck.

Wondering if folks didn't see it as much because they were trying to troubleshoot the wrong thing?  Last year, I had been thinking there was something wrong with my FPP that was causing this. 

This is difficult to resolve, since you have to "guess" where certain parts should be earlier than your normal timing marks, and always listen from the song from the beginning.  Rather frustrating when you're trying to sequence a song with elements on the beat!

[algerdes]

... Wondering if folks didn't see it as much because they were trying to troubleshoot the wrong thing? ...

This is difficult to resolve, since you have to "guess" where certain parts should be earlier than your normal timing marks, and always listen from the song from the beginning.  Rather frustrating when you're trying to sequence a song with elements on the beat!

You hit it on the head.  We too were working it as it might be a problem with FPP.  This showed up on several songs. 

[Gilrock]

I know why you see the cursor jump at least on Windows.  We tell the player which on Windows is Windows Media Player where to start playing the track.  Then while it's playing we continually ask it where is your seek value so we can correct the play marker position.  You see it jump when there a mismatch between what we've told it to play and where it really is.  And if its not playing the correct thing in line with the waveform then it's WMP's fault.

[Gilrock]

But the good news is we do have a new developer that is working on replacing how we play audio files so we may get this fixed soon.

[Ebuechner]

I appreciate the work. I don't know about anybody else but this one has been driving me crazy for a little while now.

[lorajoslyn]

That's fantastic news!  Really appreciate all the work to deal with issues such as these.  I have no idea how you guys do your day job!

[rcowan]

I can report that with the new audio libraries for 2016.10 that the timing shift issue seems to be gone. I'm not seeing it jump on me anymore. The waveform marker lines up with the song perfectly no matter where in the song I start playing from. Thank you, thank you, thank you.

[Ebuechner]

Confirmed. I just installed 2016.12 on one of my computer's and  opened a sequence that I was having a problem with and it seems to be gone. THANK YOU

[keithsw1111]

you're welcome guys