Record package creates invalid files that are too small/corrupted

[bloemy7]

Package version: 5.1.2

Environment

• OS: iOS, Android and web
• Browser: chrome

Describe the bug

We are using the Record package in a production app and seeing daily dozens of recordings that upload to a server as corrupted files. This happens both for opus as well as aacLc.
The files will be super small: 5210 bytes, 4525 bytes, etc. and are simply corrupted - as in, they are not valid.
So, to decide on the encoder, we do this:

    String fileExtension = ".m4a";
    if (_recorder != null &&
        await _recorder!.isEncoderSupported(AudioEncoder.aacLc)) {
      codec = AudioEncoder.aacLc;
      fileExtension = ".m4a";
    } else if (_recorder != null &&
        await _recorder!.isEncoderSupported(AudioEncoder.opus)) {
      codec = AudioEncoder.opus;
      fileExtension = ".opus";
    } else if (_recorder != null &&
        await _recorder!.isEncoderSupported(AudioEncoder.pcm16bits)) {
      codec = AudioEncoder.pcm16bits;
      fileExtension = ".pcm";
    }

to try and cover all platforms.

And here is the rest of the config:

int bitRate = 32000; // 32 kbps
    int sampleRate = 16000; // 16 kHz
    RecordConfig config = RecordConfig(
        encoder: codec,
        numChannels: 1,
        bitRate: bitRate,
        sampleRate: sampleRate);
    await _recorder?.start(config, path: _filePath!);

Are we doing something obviously wrong here?

To Reproduce

Steps to reproduce the behavior: I don't have clear steps to reproduce since it doesn't happen for me - it happens in roughly 1-2% of the cases, but our app heavily depends on recordings so this is a real issue.

Expected behavior

Always generate a valid audio file.

Additional context

This happens on all platforms. Would love some help here, thanks a lot!

[llfbandit]

Thanks for the report.
But there's too many variables in this issue to determine what could the culprit.
Also the files you are opening are uploaded so we can't be sure of their integrity.

For the config, I would suggest to let bit rate and sample rate to default values and see how it goes.
On some platforms, those values may be adjusted as a best effort but this is not guaranted.

Finally, since you're mixing multiple platforms, I would suggest to ensure you are using the latest transitive dependencies.

[bloemy7]

@llfbandit Thanks for your answer! Just to clarify about the uploading part - I actually log the size error before the upload happens, so this is definitely unrelated to the upload (i.e I check the file size locally on the device and then upload, but if the size is too small I short circuit with an error).

I'll try changing the bit rate and sample rate to default in case it helps.

Regarding the dependencies, I'll also check. In case you have any other idea I would highly appreciate it.

[llfbandit]

Well to find the real issue you must change only one thing at a time, otherwise it will just hide it at best.
I would say by priority:

1. Transitive dependencies update and log somehow which platform/encoder pair triggers your check. We must restrict the scope to enable investigation.
2. Configuration.

[bloemy7]

@llfbandit thanks a lot. I'm adding logging right now so I'll be able to log that. Regarding transitive dependencies, what is a good way for me to check to make sure I'm using the most up to date ones? I'm definitely using the latest record package.

Thanks again.

[bloemy7]

@llfbandit I'm really trying to get to the bottom here because this is causing me real issues with customers out there. The weird part is that I was using another flutter library previously for recording, and I was seeing similar issues. This makes me think it could be related to my implementation, yet the way I'm doing it feels pretty standard, so I'm not sure either how that would make sense. I should start having some more information with logs tomorrow about what encoder/platform is causing issues but the fact it happens both on Web and on mobile already tells me it's not one encoder only, since it'll use opus on web but not on mobile.

[llfbandit]

Just run flutter pub upgrade and check that the latest versions are used.
Safari should use aac not opus.

[bloemy7]

Thanks, I did that.

So part of the errors I'm seeing are:
File handling error: ClientException: XMLHttpRequest error., uri=..../ea2b8a8d-9a74-4a99-94c1-b2bf52163ae7
Those are very infrequent, but it basically is not able to retrieve the blog, right after we finish recording. This is on web only.

For the other ones it's still actually the file size that is too small:

It happens on web with both aac and opus (on Safari it uses aac automatically), so this seems totally independent of the platform/encoder, as it also happens on mobile.

Still trying to figure out the root cause here.

[bloemy7]

Hi @llfbandit , some of the errors that are being logged are as follows:
File handling error: PathNotFoundException: Cannot retrieve length of file, path = '/data/user/0/appname/app_flutter/da87ca44-c737-42d7-b19f-ee5980eadf73_1726858219001.m4a' (OS Error: No such file or directory, errno = 2)

Do you have any idea what could be causing this? I'm using the exact file URL that is returned to me by stopping the recording (and the same one that I give to it of course).
This only seems to happen in some cases, and only on Android. It's definitely an edge case but it happens multiple times a day for users in production. Does this happen to be a known error? This is when I try to manipulate the file right after I end recording.

Thanks!

[bloemy7]

@llfbandit finally, the other set of errors are actual m4a files that are generated but are corrupted - they won't play at all. Some of these are 8mb, others smaller, others larger. This happens on iOS only.
Do you have an idea of what could be causing this? I know these are not the most helpful bug reports but it's so strange since in general the recording works well for most cases, but in about ~5% of the times there are issues around corruption like this, which is too high to be something we can just ignore. Would love to hear from your experience what you think.

[bloemy7]

Hi @llfbandit, I'm coming back to you because we are still seeing this issue and as our usebase grows, it's happening more often. It's mainly on web, and it ends with recordings being 14kB and basically corrupted. I truly have no idea why this is happening and I'm running out of ideas. Is there any chance we can try some extra troubleshooting steps? The main issue is this is not something I can reproduce, but it's happening too often.

Thanks a lot