Sean Meighan
Software => Bugs in xLights/Nutcracker => Bugs (Please dont post here, soon to be deprecated) => Topic started by: Ebuechner on December 14, 2015, 04:40:46 PM
-
I'm having a problem with the timing while using version 4.2.2 5. If I'm sequencing and playing the song from beginning to end no problem. But if I select a point to start from in the middle or towards the end of the song I can watch the time in Decatur jump ahead and then I'm off on timing. While doing this it'll even cut the last split second off of the song and not play it. I have tried the audio with 128 and 192 constant bit rate
-
Yeah I've seen strange things like this also now that I'm more heavily into sequencing. I've noticed when I start in the middle the line likes to do a quick jump within the first second so what I do is start it back a little earlier so that the part I'm sequencing isn't near the jump area.
-
That's exactly it. It seems to be proportional to the position that you are in the song. I've tried a couple of different computers same issue every time.
-
I'm seeing this same issue with 4.3.02. I think it becomes more evident with longer songs. My audio file is a medley at just under 12 minutes long. Has anyone found a way around this or is this something that is going to be fixed? My faces look like they're dubbing a foreign film. :)
-
I had to to try this myself and there is definitely a lag, this is a sequence that I have used with Xlights since 2012 it now shows lag issues in the vis
update after I re-saved my sequence everything works perfect I can click anywhere on the time line and no lag issues with any mouth movements or any models so try hitting save sequence then re-open and see if that heps
-
update after I re-saved my sequence everything works perfect I can click anywhere on the time line and no lag issues with any mouth movements or any models so try hitting save sequence then re-open and see if that heps
Thanks Lights on Fifth,
I'll try again but I tried everything; saving, rendering, closing the app and reopening. Nothing seemed to make a difference.
-
Not sure what else to try. I've recreated the file from Audacity, making sure that it is 192 Kbps and CBR. I've saved, rendered, closed the program, opened the sequence again. Nothing fixes the issue. It is definitely exponential. I noticed that towards the end of the sequence it can jump by almost a full second. Whereas closer to the beginning it might be less than 1/2 a second. It's hard to see but if I slow the audio down to 1/4 speed then click on the timeline to start playing the sequence you can see it jump.
-
Not sure what else to try. I've recreated the file from Audacity, making sure that it is 192 Kbps and CBR. I've saved, rendered, closed the program, opened the sequence again. Nothing fixes the issue. It is definitely exponential. I noticed that towards the end of the sequence it can jump by almost a full second. Whereas closer to the beginning it might be less than 1/2 a second. It's hard to see but if I slow the audio down to 1/4 speed then click on the timeline to start playing the sequence you can see it jump.
Try 128kbps. I remember Gil saying he had a song that caused issues and he found 128 to work, but 192 didn't. Not sure if I'm remembering the thread correctly, but worth a shot.
James
Sent from my SM-G900V using Tapatalk
-
Not sure what else to try
Actually I found something else to try. I used a different audio file. One that I had laying around but that was about 12 minutes long. This file has not been through Audacity. So, I created a new sequence and played the file. No issues. There were no jumps at any point in the audio. I then took that MP3 file, opened it in Audacity and then exported it. Copied the exported file over the one that my sequence was using and bam, it starts jumping. I tried a couple of different bitrates (all CBR of course) but it didn't make a difference. So, there seems to be an issue with the MP3 encoder that I'm using with Audacity. I'm using LAME 3.99.3.
I'm going to attach the test MP3 file I was using. If someone can just verify what I'm seeing I'd appreciate it.
Just create a new sequence with the MP3 file. Don't set anything else up such as timings, effects, models, etc. Zoom in some on the timeline so that you can see every 2 seconds. Scroll over to about the 8 minute mark and then click on the timeline to start the sequence. It should play smoothly as expected.
Now, take that MP3 file and import it into Audacity. Then turn right around and export it to a MP3. Follow the same steps above for creating the sequence and testing. You should notice that after about a second of it playing that the timing bar jumps about a second.
Thanks in advance to anyone who decides to test this for me.
P.S. The MP3 file is about 27 MB. I'm not sure if it will allow me to attach it. In case it doesn't, it can be downloaded here: http://incompetech.com/music/royalty-free/mp3-royaltyfree/Perspectives.mp3 (http://incompetech.com/music/royalty-free/mp3-royaltyfree/Perspectives.mp3)
-
Try 128kbps. I remember Gil saying he had a song that caused issues and he found 128 to work, but 192 didn't. Not sure if I'm remembering the thread correctly, but worth a shot.
Thanks James. I'm willing to try anything. Unfortunately, I just tried that and it didn't make a difference.
-
Have you tried another machine?
Sent from my SM-G900V using Tapatalk
-
The question is whether its in the right location after that initial jump. If so then just start your marker earlier and don't use its position till after the jump. It's not going to get fixed unless we do a complete revamp and switch audio libraries.
-
The question is whether its in the right location after that initial jump.
Unfortunately it's not. If I watch the waveform and compare it to what I'm hearing it's definitely out of sync. However, as I posted a little bit earlier, as a test, I took a long MP3 file that I downloaded and created a new sequence with that. There were no issues. I then ran that file through Audacity and then exported it. I didn't actually do anything with it in Audacity. I just wanted to test a theory. Sure enough, when I ran the Audacified (my new word) MP3 file through xLights it was having the shift issue. So my current theory is that something in the Audacity MP3 encoder (LAME) is messing up the file. You wouldn't know it hear it. I was hoping that someone would take the file that I posted and go through the same steps to see if it happens for them or not. If it can't be reproduced then I can look at environmental issues on my side.
In the meantime, I'm splitting my large 12 minute sequence file into smaller sequences. I have 3 main songs in my show and then some filler in between them. I figured sequencing those individually would probably be better in the long run so that I can easily rearrange the show if I want to.
By the way, I'm sure you've been able to glean from my explanations what I'm talking about but for anyone else who wants to see what I'm talking about, see this video that Sean did for Gil about 10 months ago. https://vimeo.com/121568187 (https://vimeo.com/121568187) That's exactly what it's doing. However, I'm assuming that this bug was fixed since it doesn't happen at the beginning of the sequence. It's not until you get several minutes in that you start to notice it. Also, it seems to be exponential. The further you get from the beginning of the song the longer the time shift is.
-
I will try your file later today and report findings.
Sent from my iPhone using Tapatalk
-
I tried your suggestion this morning on my MAC running xlights v4.3.02. I followed the steps as you described (exported as 160 CBR) and did not see any issues. I played the file from about the 7:58-8:02 mark for at least 60 seconds.
I will try on my Win10 PC later today and report.
Dave
-
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.
-
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
-
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.
-
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.
-
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
-
No the audio library is not part of what we've been working on.
-
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!
-
... 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.
-
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.
-
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.
-
I appreciate the work. ;D I don't know about anybody else but this one has been driving me crazy for a little while now.
-
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!
-
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.
-
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 ;D
-
you're welcome guys