Audio Logger possible hour handover/ending bug

English General
1

Hi, we find that sometimes records are 1 second short of an hour or even exactly an hour and in the UI look like incomplete records (i.e. they don’t fill the whole block). This is fine but it seems a little random as to when it classes the recording as a full hour or an incomplete one and so we wondered if this was a bug? Given its only ever 1 second maximum, its probably not linked to silences (as our silence threshold is 15 seconds). Could it be some kind of glitch or stutter as it closes the file its recording to and hands over to the next one?

The file uploaded show a selection of ‘bad records’ which show as an incomplete block in the web UI vs ‘good records’ which show as a full complete block in the UI. The file also shows what we are seeing on our UI for last week which has a lot of these almost complete records.

merge_from_ofoct
merge_from_ofoct1143×1157 419 KB

(Audio Logger version 1.4.1 build 215)

2

For technical reasons (clock drift, frame sizes, the way encoders work in bassenc.dll etc.), the duration of the recordings is not exactly 60.00 minutes all the time; usually it’s a few milliseconds longer, and there is a slight overlap between the hours (the new file is started first, then the previous file is stopped).

The 3rd party calendar component tends to render this a bit “weird”. Maybe we can fix it by rounding down to the nearest second.

3

Thanks Torben. I figured it was potentially something like that. Its easy enough to tell that the recording is pretty much complete as the time in mins is shown on the calendar so no big deal, just at a quick glance it looks like there is a lot of incomplete recordings when really its only 1 second short which we’d consider complete anyway.