scanning for dropped samples

[John Ludlow]

A dropped sample will result in an out of order sequence. It will show up in a waveform by having a sudden change in value and the jump back to the correct level. This results in a pop or click. Its not an out of bounds issue. Out of bounds doesn't exist. All numeric values are valid.

Visually it would show up in the audio waveform similar to what's shown below. The issue is that a dropped buffer is not the only way these sorts of errors can occur, so you wouldn't be able to flag them specifically as dropped buffers (only a location that has an anomaly).

So, Phillip how would that be rendered in hex? Ultimately, a wav file contains a data chunk that is divided into samples (whose format is described in the wav header). What I can't get access to is how each individual sample, which is digital - and therefore a hexadecimal number after all - is specified.

[Scott P]

A dropped sample will result in an out of order sequence. It will show up in a waveform by having a sudden change in value and then jump back to the correct level. This results in a pop or click. Its not an out of bounds issue. Out of bounds doesn't exist. All numeric values are valid.

Visually it would show up in the audio waveform similar to what's shown below. The issue is that a dropped buffer is not the only way these sorts of anomalies can occur, so you wouldn't be able to flag them specifically as dropped buffers (only a location that has an anomaly).

This is exactly what I am talking about. It might happen to me once or twice in an 8 hour remote session. Maybe a few times times out of 100 hours of recording. And not on all tracks. Often, it's 2 tracks out of 10+.

[cgrafx]

don't think of it as hex, that is just the method of storage. Its literally a sequence of individual number values stored or played back at a specific regular tempo (data rate).

8-bit audio has values ranging from 0 to 255, 16-bit audio has values ranging from 0 to 65,535, 24-bit audio has values that range from 0 to 16,777,215.

In reality these numbers are ultimately normalized around 0 (either virtually via the math or physically via hardware), so 8-bit values range from -128 to +127, 16-bit values range from ***8722;32,768 to 32,767 and so on.

When a system drops a buffer, it means all the samples collected for that buffer are missing. How a dropped buffer is handled will determine what the resulting audio stream looks like. It could be dropped from the stream entirely (which would shorten the length of the audio track), or it could be filled with ones or zeros, or any other value that the programmer decides is the appropriate filler. The size of the gap (number of missing samples) will depend entirely on the size of the buffer.

Smaller buffer sizes 16, 32, etc put more demands on the audio engine and are more susceptible to running out of processing time or being stepped on by other processes. Larger buffer sizes 1024, 2048 reduce the cpu/hardware demands but increase the latency through the audio engine.

[John Ludlow]

Ah - I think I get it. Thanks! Each sample is approximating relative sound pressure at a given moment in time. That's the piece of digital recording that I've never understood. If you were to look at those values plotted, it would look like the complex wave representation of the recording. How about that... late in the game, but not too late.

So then, I presume there is a standard as to how to represent a dropped buffer - rather than whatever the random programmer chose to insert. Otherwise it would be difficult to identify them in a given sound file from one application to the next. And there is also the matter of how to represent exceeding the dynamic range of the digital medium, which might only be a single sample - but would almost certainly be a bunch of them in a row. I wonder how those are represented. I would think that it would just be the max sound pressure value since that would be easiest: a wave with a flat top (or bottom - depending...).

It seems to me that there would be no way to identify a dropped buffer in which that moment in time is simply missing. And, I'm surprised that can even be allowed to happen in multi-track recording (since the track with the dropped buffer would forever be out of synch with the rest of the tracks).

If I ran the zoo (Dr. Seuss reference...) I think I would represent a dropped buffer as a series of max-pressure samples rather than no-pressure samples (the only two reasonable possibilities) since it would also align with exceeding dynamic range and could be identified later using the same algorithm. Presuming that this is the case, then maybe you could identify them programatically by looking out for a series of samples which were all exactly that max value (whatever that happens to be for a given sample depth) - either positive or negative. You'd have to decide how many minimum samples in a row constituted that. I would think that, say, three would be sufficiently 'flat' as to not have occurred as simply a wave filling the available dynamic range.

So then, the algorithm would be to first examine the wav header - which would tell how many bytes per sample and, by extension, what the min/max value of a sample could potentially be, and also which byte constituted the beginning of the data chunk - and how many total bytes were in it. Then, it would loop through that data chunk area assembling bytes that represent a single sample and turning them into numbers in base 10. If the value for a sample were 'max' or 'min' for the declared bit depth, it would begin watching subsequent samples to see if at least three in a row were the same. If so, it would have determined that either dynamic range has been exceeded or else a buffer has been dropped.

It could probably differentiate between those by whether the number of offending samples in a row happened to be exactly the number of samples in a single buffer or not - but the user would have to supply how many samples that was because that isn't in the wav header.

Each sample would take 1/sample_rate seconds in time. So, you could also know exactly where in the recording it took place by counting the number of samples before the first offending sample and dividing that by sample-rate - which would result in the number of seconds since the beginning of the recording. And that would allow you to output to the user that at n seconds in to a recording there is either a dynamic range blow out, or else a dropped buffer. Actually, you could be much more accurate than 'seconds' too, which would allow the user to zero in on that location exactly to fix it by editing the samples within SAW.

Stereo would complicate the algorithm somewhat because left and right signals are both represented in the same data chunk. But - it wouldn't complicate it that much. This could be done... and so, I presume it probably has been done. Or else - I have glossed over some detail.

[Dave Labrecque]

This is exactly what I am talking about. It might happen to me once or twice in an 8 hour remote session. Maybe a few times times out of 100 hours of recording. And not on all tracks. Often, it's 2 tracks out of 10+.

If it's only happening on some tracks and not all, I'd worry not just about the sound, but about the sync between discrete tracks, which would be shifted if all of the the dropped samples aren't replaced with some default-value samples as Philip seems to indicate can happen depending on the audio driver in use.

[jmh]

I think there lot of different approaches that could be employed like maybe running the tracks through narrow band eq and looking for peaks that are out of character with the rest of the audio then looking for approximate matches for suspect sample numbers across the different bands.

I would look in at open source audio utilities for de clicking utilities. The command line utilities like sox (don't know if it does declicking) have tons of flags to put it in inspection mode - or maybe a verbose mode that would indicate what and where it processed a file. On linux or a mac, you might discard the audio output by piping it to /dev/null, but use the console output to tell you what to look for.

Now I'm remembering posting a similar comment on a related thread about a year ago - then poking around and finding a couple of interesting utilities - but at the moment, I don't remember what they were or did.

[jmh]

That didn't take too long:

http://www.sawstudiouser.com/forums/...ighlight=linux

mediainfo

...don't know that it will help for this, but something to look at.

[jmh]

I think there lot of different approaches that could be employed like maybe running the tracks through narrow band eq and looking for peaks that are out of character with the rest of the audio then looking for approximate matches for suspect sample numbers across the different bands.

A recursion of this technique that would next look for approximate matches across multiple tracks might be pretty effective in identifying trouble spots.

[cgrafx]

If it's only happening on some tracks and not all, I'd worry not just about the sound, but about the sync between discrete tracks, which would be shifted if all of the the dropped samples aren't replaced with some default-value samples as Philip seems to indicate can happen depending on the audio driver in use.

Bob would have to chime in here to be 100% sure, but I'm about 99.9% that Saw Studio (and I suspect really all recording tools) don't shorten the file length but rather fill the space with some form of blank data. I was only pointing out what the possible options were.

[jmh]

Something else occurred to me and that is you might run the files through a utility to display them as a spectrogram. A quick visual inspection might give you a quick way to find trouble.