"Compressed" (in time) audio in time when recording

[rgomez]

Hello,

I have some cases, that I haven't been able to reproduce or identify really what could be the cause, where when recording a certain lenght everything finishes correctly, and at the moment that it's expected, but the final audio file has a duration less than what is expected.

The audio finishes where is expected, but the length of the file is not. Say, I have a marker that happens at the start of every hour, so If I record from that to the other marker, I would expect an hour long audio file, but the resulting audio is just, for instance, 58 minutes. But you can hear the two markers on the audio correctly.

This only happens ocassionally, and just in some computers/interfaces. I can't find what triggers it. Even in the same computer, without any changes to the configuration (of the audio interface or my app), some days it works without issues, and some other days it does not.

In this particular case I am reviewing right now the Audio interfaces are two Behringer UMC22. The sample rates in the whole chain are the native ones for that interface, 48khz, as far as I can tell. The RecordStart call is using BASS_SAMPLE_FLOAT (in theory the samples from the interface are 24bits). The final audio file is an opus encoded one, using the external opusenc.exe tool. I could try also with some other codec, but I don't think this is related to that.

This looks to me as if the sample rate was incorrect "somewhere" but being that the same settings work fine one day, and the next one they don't, don't make sense to me. There is no noticeable change in pitch nor something like that in the audio, but being that the difference at the end is usually just ~3% of the expected length I guess one would need special tools to identify the change in the audio itself.

This are standalone computers that have no user: it's just a service that runs continually and records the whole day. So at 00:00 it finishes the recording from the day before and starts the new one.

I saw this post: Bug Recording "slow" and low pitch and I'm going to try that option and see if it solves the issue. It was the only post I could find related to this.

But I am open to suggestions or ideas to try. As I said, I haven't been able to reproduce this with the computers and the audio interfaces I have access to, and that makes things more difficult...

Thanks in advance

[Ian @ un4seen]

If the problem only happens occasionally then perhaps the issue is dropped data rather than the data rate? Perhaps the encoding is introducing a delay (eg. IO delay) sometimes, which results in the recording buffer overflowing and data being lost/dropped. If you aren't already, try using the BASS_ENCODE_QUEUE flag to prevent encoding delays holding up the recording. You could also try using the BASSenc_OPUS add-on (BASS_Encode_OPUS_StartFile) instead of opusenc.exe.

If the problem persists, please check what BASS_ChannelGetPosition says about the recording and BASS_Encode_GetCount(BASS_ENCODE_COUNT_IN) says about the encoding. Do they match and do they show the expected value or the shortened value?

[rgomez]

Hello Ian,

Thanks for your reply.

I don't have any of those options/methods in use right now, but I will implement them to have some more info.

I don't remember why we are using the opusenc.exe, probably because when this project started the OPUS encoding plugin was not available. I do have the option to use that path, IIRC, so it should be simple to try that option. I believe in the past I tried moving to the plugin but something blocked me, maybe it was just that the external encoding was using the latest opus version, but I think the plugin now is using the latest version of the library, correct?

Apparently we have an installation where this problem happens all the time, so we are going to change the option to use DirectSound instead of WASAPI, which is what we can change now and see if it helps. We could also try the OPUS plugin there.

Thanks!

[Ian @ un4seen]

I think the plugin now is using the latest version of the library, correct?

Yes, the current BASSenc_OPUS release (2.4.4) is using the current libOpus (1.5.2) code.

One thing to mention is that when using the BASS_ENCODE_QUEUE flag, you should use BASS_Encode_StopEx with queue=true to have the encoder process the queued data before stopping.

[rgomez]

Hello Ian,

Thanks. I have modified the app to output the BASS_ChannelGetPosition against the BASS_Encode_GetCount(COUNT_IN) and so far those always are on the same byte.

Still, in one of the computer where we have seen this problem I got a report of the same "compression" at the end of the recording. I checked the log and the ratio between those two values was 1.0 for the whole day.

I have instructed them to enable the Queue option (I also added that) and I am waiting for info on how it worked... although if I understood correctly, for the queue to be a solution I should have seen different values between those 2 counts mentioned earlier?

I haven't enabled the internal opus encoder, although it's an option in the app already, yet; waiting to see if we can find the issue or at least discard possible causes.