[BUG] Recording sentences on a low-battery laptop or slow machine leads to a glitchy and fasten voice clip

[irvin]

Describe the bug
Recording sentences on a low-battery laptop leads to a glitchy and fasten voice clip.

I suspect that this is also happening on low-speed / old Android, and happen on all slow devices.

To Reproduce
Steps to reproduce the behavior:

1. Use all your battery until your windows goes into engery saving mode
2. Recording one sentences
3. Click replay on the sentences
4. You hear the glitch voice.

Expected behavior
We should add a banner tell people "Don't record while your battery is low" when we find the battery is low (if we can)
or "Don't record on this device" when we find the device is too slow

Screenshots
mp4 video: https://github.com/user-attachments/assets/11f5137c-9e11-41b4-b771-5c36eef2071f

view on youtube: https://youtu.be/O7A2_GMKRzw

Desktop or Mobile (please complete the following information):

• OS: Windows (I reproduced it on Win 11 in Parallels on Mac)
• Browser: Edge
• Version: N/A

Additional Hardware (were you using headphones, an external speaker or an external microphone?):

• run out your battery until last 5 min
• Type:
• Model:

Additional context
Add any other context about the problem here.

[jessicarose]

Thanks so much for flagging this, the recording issues on a low battery sound like a bit of an edge case but I agree that the possibility that this is also happening on slower mobile devices needs more investigation. I'll add this to the backlog to look into in more detail, but it might be a bit of time until we find resource for it. If you or any community member has more context, it would be so welcome!

[irvin]

Hi, it does not always need a low battery. I just used this method to reproduce the issue, but you will see this glitch only on slower machines without plugging in the laptop charger.

From our experience with teachers in rural areas with non-top-level laptops, in many cases, their clip is broken without going into Windows eagerly saving mode, just not plugging in, so I believe there is a specific speed criterion that we need to look up.

We have also randomly heard this kind of broken voice for many years, but we can finally understand why.

[HarikalarKutusu]

It happens from time to time.

I always though it was because of oxidization of the phone jaks.

This is a great find. Thank you @irvin !

[irvin]

I think we can do random sample testing on the current database to see the percentage of glitchy clips.

[HarikalarKutusu]

I already have SNR calculations for all datasets. I think such recordings could fall into high SNR cases.

I released the statistics and low SNR record metadata. You can reach "bad recording data" here.

Edit: Some explanation.

I calculated all, but reported only low Signal-to-Noise-Ratio recordings, as part of dataset quality measurements. Here is the methodology.

Low SNR might mean many things:

• Whispering (and some background noise)
• High level background noise
• Technical noise (high hissing, cracks etc)

Some of the last one "might" include our cases. So I proposed "instead of checking over a sample, you can look at the ones in those problem ones".

There are 25M recordings, so a reasonable statistical sample would be large (~13.800 recordings).

[irvin]

I already have SNR calculations for all datasets. I think such recordings could fall into high SNR cases.

I released the statistics and high SNR record metadata. You can reach "bad recording data" here.

The link only pointed to a folder of lots of meta files.
So, how many is the broken rate on average in all locales?

[HarikalarKutusu]

Added some explanation above.