Sean Meighan
Software => xLights Convert => Topic started by: nmiller0113 on October 28, 2015, 04:47:06 PM
-
I'm throwing this out there as I'm seeing this as a new FPP user. Here's some context. I've been using the latest version of LOR S3 for many years and have about 24 sequences I've built out over the years. I decided this year to start using xLights as my sequencer and did a data layer import of all of my LOR S3 sequences into the latest version of xLights. To add a bit more context, I've been using LOR S3 player in previous years and I did tests in the latest version of xLights, not just using a visualizer/layout but with my controllers and lights...and I've never seen any sync issues in the LOR S3 or xLights players.
So, I then decided to move down the FPP path as many of you have. All installed well and looked good. I'm running on a Pi2 with 32GB flash for the appliance and 64GB USB Flash (high end/fast) for the media. I then started testing and went through playing all of my sequences with the controllers and lights. To clarify again...These are all fseq files from data layer imports in the latest version of xLights from LOR S3. The result is I found that all of my data layer imported sequences have my lights ahead of my audio by ~300ms. So I started working with the team over at Falcon and we went through many different tests...only one proved to yield different results. If I create a new xLights sequence without any import from LOR S3 I don't have any sync issues. So the only thing I can think of is there is something happening when the fseq is created and a data layer import is included...the strange thing is, these imports work just fine in the xLights player.
So at this point...I'm at a loss. I have a couple different fseq's, xml and lms files I'm willing to share for someone to test with and see if they are getting the same results as me. The falcon folks have seen the same delay from my fseq's with the exception of the one that didn't include a data layer import. I'd love your thoughts :)
Here is the link of the issue on the Falcon forums if you'd like to read further...thanks for your time in reading this!
http://falconchristmas.com/forum/index.php/topic,3190.0.html
-
Why didn't they just have you import an LMS sequence that only turns on one node for 1 frame and then you can analyze the FSEQ file to see exactly where the data lands. They should be experts on the layout of those files.
-
And actually data layers are saved in ISEQ files which are basically exactly the same as FSEQ files except we used a different extension to know how to use them. The same function is used to read both file types so we can't be reading one different from the other. I've had 250ms offsets using the Pi in the past and had to trim my audio to fix it when I moved for LOR to xLights and that was before data layers existed.
-
This question got my interest over at the Falcon forum also because I was experiencing the same thing but nit with imported files. My sequences are entirely done in XL4 abd I noticed that when I ran them from the PC, everything was in sync but when I ran from the Pi, it was out by 180ms for both sequences. I just made the adjustments in the audio offset and all seems to be ok so I "presumed" that it was a function of the Pi. But apparently this isn't the case for everyone.
So for me at least, it's not due to some "importing from LOR thing" so for the future i'll be interested to hear what the cause is. As I can get it all in syn using the offset, I'm happy. The offset is exactly the same for the two sequences that use two different multi-track,chopped up and merged music files in audacity.
-
If I remember correct they said they were going to add the capability to apply an audio offset correction factor in the Pi. I thought that was added in the last year.
-
Why didn't they just have you import an LMS sequence that only turns on one node for 1 frame and then you can analyze the FSEQ file to see exactly where the data lands. They should be experts on the layout of those files.
I could do that for them, but wasn't ever asked. I think majority felt that it is too close to Christmas at the moment and they'd like to continue troubleshooting this after the holiday season.
-
And actually data layers are saved in ISEQ files which are basically exactly the same as FSEQ files except we used a different extension to know how to use them. The same function is used to read both file types so we can't be reading one different from the other. I've had 250ms offsets using the Pi in the past and had to trim my audio to fix it when I moved for LOR to xLights and that was before data layers existed.
I'm not sure I'm following how this relates, but that may be due to my being new to both xLights and FPP. I did understand that the data layers were saved in the ISEQ files, but aren't they also saved in the FSEQ file? I ask because I'm only transferring the FSEQ file to the FPP and it plays the data layer. Were you mentioning that because the xLights player actually uses the ISEQ file? Sorry if I wasn't following.
Wouldn't trimming the audio file then make it so the sequence would now play out of sync on the xLights player? I don't know if you saw this part in my previous message but the sequence played fine in the LOR S3 player as well as the data layer import in the xLights player. It is only out of sync on the FPP. is it normal that it would play fine on two other players and not on the FPP? This leads me to the part that makes me shake my head. If I build a new sequence in xLights using the same mp3 (unmodified) and don't do a data layer import, I just do sequencing in xLights and then play that on the FPP, it is in perfect sync.
-
If I remember correct they said they were going to add the capability to apply an audio offset correction factor in the Pi. I thought that was added in the last year.
Yes, they have it and it works just fine. This is how I figured out exactly how far ahead my sequence in comparison to the audio. I'm just trying to figure out why it plays fine in the xLights and LOR S3 players but not on the FPP. Then, as I mentioned previously, if I make a brand new sequence using the same mp3 that was out of sync before without doing any data layer import it plays perfectly in sync on all three. It's puzzling to me.
-
I read your thread on the FPP site. You were given files from the Captain and they played out of sync for you also so I think you are going off track thinking it has something to do with data layers. Yes data layers are stored in ISEQ files but they get merged in with all the other effects when you save and the FSEQ is created. I'm just saying both files are the same format. You would get the exact same result if you used the Convert tab to bring in the LMS file into an FSEQ format.
-
Interesting thread.
I bought a couple of sequences from Holidaysequences that are in SUP format. I added the LOR SUP to my tree, while the rest of the elements were already sequenced. I too noticed a .3 sec offset and ended up adding .3 sec to the beginning of the audio file. That fixed the import, and then I had to adjust the rest of my effects/models where the difference was noticeable.
-
Interesting thread.
I bought a couple of sequences from Holidaysequences that are in SUP format. I added the LOR SUP to my tree, while the rest of the elements were already sequenced. I too noticed a .3 sec offset and ended up adding .3 sec to the beginning of the audio file. That fixed the import, and then I had to adjust the rest of my effects/models where the difference was noticeable.
I've noticed a bunch of the Holidaysequences stuff are off a bit. The worst one I've seen from them is about 3 seconds off. I've been debating adding an "Offset" spinner to the import dialog to automatically offset everything by that amount at import time.
-
Interesting thread.
I bought a couple of sequences from Holidaysequences that are in SUP format. I added the LOR SUP to my tree, while the rest of the elements were already sequenced. I too noticed a .3 sec offset and ended up adding .3 sec to the beginning of the audio file. That fixed the import, and then I had to adjust the rest of my effects/models where the difference was noticeable.
This lag was in noticed on xlights or fpp?
-
This lag was in noticed on xlights or fpp?
I'm not sure we could call it lag, because on the flip side of that coin you could also call it lead in the sequence. Not to nit pick, but I'm trying to avoid confusion. I've been referring to it as out of sync.
The sync issues only presented itself on the fpp, not any other player.
-
This lag was in noticed on xlights or fpp?
I'm not sure we could call it lag, because on the flip side of that coin you could also call it lead in the sequence. Not to nit pick, but I'm trying to avoid confusion. I've been referring to it as out of sync.
The sync issues only presented itself on the fpp, not any other player.
I was actually asking Steve about his experience.
-
It's a fixed offset I'd say and not a lag. You can clearly see the effects start just a bit behind the audio peaks. It could be very well that I did not have the exact same song as the author.
-
Yeah this sounds like two different scenarios. Miller's issue is it plays fine in xLights and then lags on the FPP whereas Steve had an offset in xLights after importing. My issue in 2013 was similar to miller's. I had to shorten my audio 250ms at the time because there was no offset option in FPP yet. Also back then we had to convert all our audio to OGG format so I really haven't dug into this and tried with MP3's. I'm pretty sure my 2014 show just continued to use the OGG files I had already shortened but I ran some new songs with MP3's that I don't believe I shortened at all.
-
It's a fixed offset I'd say and not a lag. You can clearly see the effects start just a bit behind the audio peaks. It could be very well that I did not have the exact same song as the author.
Yeah, mine is definitely different. For one, mine is with the effects ahead of the audio, rather than behind. But I was the author on the ones I'm testing with and the mp3 has been the same from the start.
-
Ok, so I see this thread is primarily about imported sequences being out of sync but I'm still curious as to why this would be the case with my sequences created entirely in Xlights with no importing from other sequence types being done and using the audio files that I created in audacity. Or did I miss this bit being discussed earlier in the thread. As I said earlier, the offset works but it occurs in sequences natively created in Xlights. It shows no sync issues using the xml from the pc. Admittedly haven't tried running the fseq file from the pc, just from the Pi.
-
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 :)
-
I converted all of mine to 192K. Some were higher bit rate and some lower to start. I just checked two and they match your scenario to a T. I can't believe I have not noticed it.
-
I did a conversion with another program I had that came with a video editing package Sony Source Forge and it was better but still has some extra space, just less. I then tried a utility called mpTrim that was able to take some space out of the begging but it's not still not exact. If there is a better way I would like to know. Maybe trim some space before the conversion. Other than that you basically come as close as you can.