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

[Pangolin]

Guys, if anyone is having such problems, send all related files to us for analysis. Since we wrote all of our own codecs, we have 100% control over all of this stuff. I don't want to take for granted that VBR will be unreliable. I'm basically unwilling to make that assumption and also unwilling to jump to any conclusions until we've seen the problem with our own eyes and then had a chance to fix it.

The problem could be entirely and easily solvable, but we always need to see what is happening and then analyze the problem.

Bill

[The_Doctor]

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.

Then you have good timing. Keyboard has far faster response than mouse, which helps. True for PS2 anyway (I stay with good quality older gear rather than chase budget end latest stuff. (Bad habit, that, I find..)). I'm not sure what USB keyboard timing is like. I suspect worse than PS2.

Sound Forge will drop a marker like that too, with the M key. I rarely do it that way in realtime audition unless the work I was doing has tired my eyes while sharpening my physical, musical response, because once you're in a sample-per-pixel scale that marker is a few screen-fulls away most times.

Bill just said he doesn't want to rule out VBR as being ok. I think he's right not to because it depends on how it's used. Straight sequential playback should always be ok for the simple reason that VBR was intended to cope with that in the first place. There may even be ways to extend its accuracy when seeking. One method would be to always fetch data from a frame boundary guaranteed to be earlier than the exact moment wanted, then search for a string of bytes captured from the original data used during the original marking event in the decoded PCM data. I have found that in a video file hundreds of megabytes long, a 32 byte substring is usually unique. If you're limiting scope to a few compressed frames earlier in the much smaller data set per unit time of most audio files, and no more than a similar amount later, the substring to search for might be extremely reliable if it's only 8 bytes long, provided the sound was not a very simple fixed frequency wave. (Actually if that wave had been recorded through an analog link it may still produce unique 8-byte substrings in a few seconds of decoded PCM data). Tests would be needed to see if this allowed seeking in VBR files to get one-sample accuracy without strong momentary CPU demand spikes while it decoded/searched/trimmed/buffered the data for output, but I think it could work well, adding just 8 bytes to marker data, and it could make VBR (and ABR) as good as CBR in all situations in any tool that used this method of marking time. Bill, if you agree, and want to use the idea, have at it.