tl;dr - Audacity inserted ~50ms into my MP3's when I converted them from 256K CBR to 192K CBR to meet an xLights requirement I saw in a post. This was the root cause of my issue. For those who want more details...keep reading...
I'm happy to say that I've gotten to the bottom of this issue. Please bear with me while I explain my findings as it will, hopefully, make sense to everyone. This issue drove me crazy a few months ago, and most recently tonight. Up until tonight I had pretty much set my FPP delay to 250ms and forgotten about it. That was until this week when I started sequencing additions to my old sequences I had imported from LOR. Let me add some more context. Up until this week I had really just been using my imported sequences from LOR into xLights and then into FPP. When I first did that I noticed that the lights were ahead of the music...somewhere that looked to be ~150ms - ~200ms. That was just a best guess with the naked eye. The gist of it is, they were not working together.
Fast forward to tonight and this week in general. I've added some models to my current display that didn't exist last year. So I started sequencing them into my data layer imported LOR to xLights sequences. I kept noticing while sequencing in xLights this week trying to add effects to my new models that my old sequences in the data layer seemed like they were off time in xLights in parts. I immediately chalked it up to something buggy in LOR, haha, or that xLights just allowed me to be more precise and my old sequences were just strangely off in spots. I continued to sequence the new effects to the new models in xLights in the sequences with the data layer import thinking nothing else of it. Tonight I finally premiered the additions to the data layer imported sequences and noticed that all my new sequencing to the new models not imported were delayed / behind the music. So I went back into xLights and reviewed it in depth and got super granular in checking my timings with the song...even slowing the song down to a crawl. Nope. My new sequencing was spot on...well..at least close enough that there was no way any off timings in my sequencing would be as blatantly obvious as it was when I watched it live on the lights. Strangely, the data layer imported stuff looked right on time still. Huh?!?!
So then a I had a thought. I knew I had a +250ms media setting enabled in the FPP. Hmmm. Could that be it? So after the show was over tonight I went outside and did some testing. I disabled the +250ms setting and ran one of the sequences again. The new stuff was now on time and the data layer import was now off time. Well, I immediately started digging in thinking it was related to the xLights import process. I then did a comparison down to 50ms (what my sequences are built as in both xLights and LOR) and noticed there was zero difference in sequences start times between either. So that ruled out xLights importing as an issue.
Then it all hit me like a ton of bricks...WHY DIDN'T I THINK OF THIS BEFORE!?!? There was one other change I had never considered being a factor in all of this. When I was switching to xLights I recalled reading somewhere that I needed to convert my MP3's to 192K CBR. So I did. Little did I know, that turned out to be the root of my problem. All my MP3's I had been using in LOR were already converted to CBR, but they were all 256K...so this is why I converted them to 192K. I had a hunch that maybe something happened in the Audacity conversion. Luckily I had saved my previous 256K CBR's that I had used in LOR, so I compared the 256K CBR MP3 to the 192K CBR MP3 and BANG! Somewhere in the conversion Audacity decided to add ~50ms to my converted 192K CBR MP3. The same ones I used to build all my sequences that I imported LOR into my data layer on in xLights. This explains everything. It explains why nothing seemed off in LOR and why it did in xLights.
So, as it turns out it had nothing to do with either LOR or xLights OR the FPP, so I apologize for wasting everyone's time troubleshooting this mysterious issue. I'm now going to post this to the xLights forum where I asked about the same problem thinking it may be an xLights issue. I've attached the screenshots as proof of my findings and to those of you out there converting any of your previously used MP3's with Audacity..be aware of this potential nuisance.
After doing a bit more research it seems that this is a normal characteristic of MP3 encoding. It appears that OGG may be the route to go to avoid this in the future. Does anyone have any thoughts or experience with OGG in either the FPP or xLights? As far as I can tell it seems supported. Just didn't know if there were any caveats. Here are the links to where I found this information when searching Audacity forums:
http://forum.audacityteam.org/viewtopic.php?f=46&t=85476
http://lame.sourceforge.net/tech-FAQ.txt
Do we really need to have all of our MP3's for xLights as 192K CBR or will my 256K CBR MP3's work just fine? If so, all my problems will be gone. I'm hoping that requirement for xLights was related to some old bug that has since been resolved!
Sorry for the long winded post and thank you to all of you who made it this far and didn't just stop at the tl;dr
