BEYOND - Important audio delay (not in sync with the audio graph)

[White-Light]

Now, I mentioned Sound Forge for a specific reason: I use it, so I'm familiar with some of how it works by long habit. When placing a marker the first thing to do to correctly set a point is to find it, no marker gets dropped till the last move. I've tried dropping them on the fly, and it's a terrible method. What you do is zoom to some fairly close view with up/down arrow keys (fastest way to change zoom scale), and start playback live from as far back as you need to, then hit ENTER, not Space, so next time Space starts it playing, it starts where it stopped, not where it played from last time. If you overshot, hit PgUp to go back, alternating Space to start/stop until you're close. Zoom in to fine tune timing of start point if needed. This can be a very fast series of moves with practise. The moment your Space button starts the beat with precision, drop the marker and move on in realtime listening for the next instant to hit Enter. Hit Space the first time or two just to be sure, it's quicker to adapt your own responses than to fumble it and move badly placed markers later.

That's pretty much what you do in laser software (short cuts aside) and everything will be sync'ed. However once its been saved and re-opened then everything is unsync'ed with MP3, albeit only by a fraction usually, but nevertheless enough to spoil a show. WAV's etc are unaffected. Something seems to change in the MP3 timing wise between openings that throws the markers / cues a fraction out.

[dnar]

Yes!

I remember reporting this years ago to you and working through a bunch of tests.

VBR is mainly a problem when the file is used to create show. If you scroll to a random position within the audio file and begin playing from that point the time that comes from the media player is not necessarily the same time that would be reported if you played the song from the beginning. When people create shows they jump all over the place within the audio files so when they play it back all at once the timing is way off. As far as whether or not there is a timing drift when playing back the song from beginning to end goes, I don't believe so because I did a lot of timing checks when I was troubleshooting this issue. Constant rate MP3 and WMA files don't seem to have this problem, though. Using WAV files might be overkill but it certainly is a good way to avoid the problem.

[dnar]

This can be simplified by entering the BPM of the track, giving you markers on the beat, at least up to the point the BPM changes as is sometimes the case.

Because when you're trying to put a show together its very difficult to drop a marker on the exact note you want because of the speed with which the cursor moves, or if zoomed out to slow the cursor down because you simply can't see the peaks in the waveform as a result, so the logical way to do it is to expand the time line so you're zooming in, then set playback markers on the section you're working on and then play back multiple times and move the marker etc a little each time until you have the marker and cue in exactly the right position that corresponds to the beat or highlight in the music that you want to emphasise.

To do that with a straight play through would be:

1: Nigh on impossible with regards to alignment because its simply not possible to drop accurately when zoomed out or react fast enough when zoomed in

2: Very, very time consuming as you'd have to allow the tune to play all the way through for every key / cue (bearing in mind a show might contain hundreds of keys / cues). OK when placing keys in the 1st few seconds, but when the show is several minutes into the tune, the time taken to place each cue / key rises exponentially if you have to wait over 3 minutes of play through to place every marker etc. and bear in mind that whilst 3 mins would be painful some songs run to nearly 10 minutes!

[kl79]

I have this problem, for all shows only if I launch "Beyond universe" while playing a show.

The show start "un-sync" with the music if I do that, and that's not a music file problem.

[White-Light]

I have this problem, for all shows only if I launch "Beyond universe" while playing a show.

The show star "un-sync" with the music if I do that, and that's not a music file problem.

I've just tried with the default universe open and played back a show from a member on here and it's sync'ed perfectly. I only have the default Universe layout though. I wonder if this is a sync issue or a system resource issue. Is it on a powerful pc and have you tried enabling the resource monitor in Beyond and seeing what is happening resource wise? If it's a bug then it needs reporting to Pangolin but it could be resources.

[The_Doctor]

This can be simplified by entering the BPM of the track, giving you markers on the beat, at least up to the point the BPM changes as is sometimes the case.

Only if the music is precisely metronomic. Musicians rarely are, there is subtle rubato (changes around some fixed tempo) and actual tempo changes too, in almost all recordings not synced to a click track. Jet Black of the Stranglers is a 'metronomic' drummer when he wants to be, but even he does it. It takes only a few seconds worth of parallel metronome to prove it.

One thing that can screw up markers on saving so they're wrong on reloading is time based marking. If you can set the time gauge to samples and not beats/ticks, or real times, the save/load operations will preserve the markers. This is true for Sound Forge, and likely for anything where the beat/tick resolution is a lot cruder than single PCM sample duration.

If a VBR MP3 is loaded for audio, and markers are being screwed up even when no seeking is being done randomly (or otherwise) in the VBR file, then check that the MP3 data isn't being recompressed back to MP3 on saving! I doubt that Beyond or pretty much anything will do this, unless it's an audio editor that is assuming you want it to do it. Check anyway though because it's bad for the sound, worse every time it happens, as well as messing with relative timings.

Whatever the cause of timing error is, try to find out what it is. It may not always be obvious. Evidently not as there seem to be at least two unsolved instances mentioned in this thread already. The one thing to remember is that if the audio SOUNDS right, it is right, because that's the whole point of a working audio subsystem, to make it sound right. Whatever the frame size or rate or compression method, timing should remain accurate relative to start (and to any other marker that is also correct relative to start). This is obvious which is why it's a good reality check. If no seeking is being done, and if audio and video start together, and are clocked by accurate timers, they'll stay in tight step for days. So if these conditions are met, and your timing still gets wrecked, look elsewhere for the answer.

[The_Doctor]

I've just tried with the default universe open and played back a show from a member on here and it's sync'ed perfectly. I only have the default Universe layout though. I wonder if this is a sync issue or a system resource issue. Is it on a powerful pc and have you tried enabling the resource monitor in Beyond and seeing what is happening resource wise? If it's a bug then it needs reporting to Pangolin but it could be resources.

Seconded. Look for spikes in CPU demand. It takes a strong burst in demand to prepare and fill buffers from data on a disk. Allow lots of spare overhead, shut down unwanted processes, etc... If Beyond has lots of surges in demand in normal operations then Pangolin may be able to find ways to smooth that out to ease the problem. (I'm not saying it does, beyond the essential startup conditions, but those who have it can check for this).

Always launch the processes you want in advance if possible, just leave the event triggering till the instant you need it.

[masterpj]

I have this problem, for all shows only if I launch "Beyond universe" while playing a show.

The show start "un-sync" with the music if I do that, and that's not a music file problem.

email bill. they will sort out the problem. They haven't got time to constantly lurk on PL.

[White-Light]

email bill. they will sort out the problem. They haven't got time to constantly lurk on PL.

He ought to check resources 1st PJ as there may not be an issue. We don't know the power of his laptop or resources available. Once that's eliminated its Pangolin time. Otherwise if he contacts Pangolin 1st they could spend lots of time looking for a bug that doesn't exist if it turns out to be a resource issue.

[dnar]

And that is why I miss the feature in Spaghetti that allos s you to lay down your own markers via the space bar in time with the beats. It works very well.

Only if the music is precisely metronomic. Musicians rarely are, there is subtle rubato (changes around some fixed tempo) and actual a tempo changes too, in almost all recordings not synced to a click track. Jet Black of the Stranglers is a 'metronomic' drummer when he wants to be, but even he does it. It takes only a few seconds worth of parallel metronome to prove it.

One thing that can screw up markers on saving so they're wrong on reloading is time based marking. If you can set the time gauge to samples and not beats/ticks, or real times, the save/load operations will preserve the markers. This is true for Sound Forge, and likely for anything where the beat/tick resolution is a lot cruder than single PCM sample duration.

If a VBR MP3 is loaded for audio, and markers are being screwed up even when no seeking is being done randomly (or otherwise) in the VBR file, then check that the MP3 data isn't being recompressed back to MP3 on saving! I doubt that Beyond or pretty much anything will do this, unless it's an audio editor that is assuming you want it to do it. Check anyway though because it's bad for the sound, worse every time it happens, as well as messing with relative timings.

Whatever the cause of timing error is, try to find out what it is. It may not always be obvious. Evidently not as there seem to be at least two unsolved instances mentioned in this thread already. The one thing to remember is that if the audio SOUNDS right, it is right, because that's the whole point of a working audio subsystem, to make it sound right. Whatever the frame size or rate or compression method, timing should remain accurate relative to start (and to any other marker that is also correct relative to start). This is obvious which is why it's a good reality check. If no seeking is being done, and if audio and video start together, and are clocked by accurate timers, they'll stay in tight step for days. So if these conditions are met, and your timing still gets wrecked, look elsewhere for the answer.