Inconsistent behavior with very long audio files (LIMITATION)

[Picorims]

Describe the bug
When opening a very long audio file, it is unclear whether the app is loading or can't support it. The app seems to freeze or stop responding.

To Reproduce
Steps to reproduce the behavior:

1. load a long audio file (more than half an hour)
2. Try to play it
3. Try to save it
4. Try to export it

Expected behavior
The app notifies when it can't proceed the audio. (This would be an evolution)

Desktop (please complete the following information):

• OS: Windows 10
• Version 0.3.3-beta

Additional context
The length required to reproduce the bug depends of the computer capabilities.

[Picorims]

Stress test of 30 minutes: PASSED

• specs: quadcore Intel core i5 CPU; no graphics card; casual hard drive
• load: OK (~20s)
• save: OK (~3-5min)
  • The biggest bottleneck seems to come from the zipping part, it is unclear whether the size or the length affects performance.
• export: OK (~1h in 420p with jpeg export)
  • the initial setup involves copying the file (depends of the file size), converting it in multiple structure types (depends of the length), and interleaving in the case of stereo (depends of the length). Adding logs between each steps has shown that it takes a little while but the app is not freezed, even if the progress bar stays at zero the whole time.
  • Disk space used during export remained acceptable, with images below 100kB of size.
• The whole test took approximately 2 hours.

TODO: stress test of 2 hours (expected to take much more time, unlikely to work).

[cantecim]

Hello @Picorims, thank you for this great project!

Is there any update on the issue? I came up with the same issue, 01:02:23 hour length audio. load is OK, save is OK, when I try to export, opens a borderless separate window and it just hangs that way

I'm using Windows 10 with 16 GB RAM and AMD Ryzen 5 2600X Six-Core Processor 3.60 GHz
Here is the latest lines of the log file

[2023-09-03T22:04:10.139] [DEBUG] export - save loaded into the renderer
[2023-09-03T22:04:10.147] [INFO] main - export window: new size: 3840x2160
[2023-09-03T22:04:10.155] [INFO] export - loading audio...
[2023-09-03T22:04:10.173] [INFO] export - audio loaded successfully.
[2023-09-03T22:04:10.186] [DEBUG] export - using audio: D:\Program Files\Wav2Bar\app-0.3.3-beta\resources\app\temp\temp.mp3
[2023-09-03T22:04:10.187] [DEBUG] export - processing audio...
[2023-09-03T22:04:10.187] [DEBUG] export - audio source: D:/Program Files/Wav2Bar/app-0.3.3-beta/resources/app/temp/temp.mp3

[Picorims]

Hello @cantecim ,

Unfortunately I do not plan to fix this issue as of now as it is complicated and non trivial to fix (quite a lot of refactoring to do). If I do fix it, it will likely be in a rewrite that I don't know yet if I will do it or not. I'd much rather improve everything at once than continuously refactoring a project full of tech debt and issues.

Note though that it might hangs for a while for such long files, because under the hood it does heavy processing on the audio buffer, that is not logged (it never came to mind those could be such a huge bottleneck). The audio buffer being so big, a single task can take a while and there are multiple of them.

You can try to let it run for a while and see if it succeeds. (The additional delay will be on the audio initialization, the frame rendering speed should remain unchanged, it will just start way after export launch). I can look for publishing an update with additional logs on export to log progress on these tasks eventually if that can help you (and if I have the time for it, too). But that is pretty much it I think.

If there is a lot of demand around the issue I will see if there is a workaround that I can try to implement to help exporting long audio files but since it'd take me a lot of free time I'd prefer spend it on clean foundations instead.

[makkura]

I just wanted to add notes from my experience with this issue and what I am doing to handle it for my use case.

Notes:
The first spot this tends to break at is in export_renderer.js where it generates the PCM array.
This starts within the block at roughly lines 170 - 190 that generate the PCM array from multichannel / single channel audio.
It looks like it overflows when generating the Float32Array.
Switching this to other array types with to try to hold the full length of the content eventually generates more errors down the line. In theory, this might be used to resolve the issue by fixing it down the line as well but you'd want to be sure that the type in use doesn't lose data and generate incorrect results later. I have not dug into that at this point.

My specific resolution:
The audio I'm handling is mono despite showing up as multi-channel.
I have been using sox to convert it to a single channel, halving the array length so I can bypass the overflow issue.

[Picorims]

Thanks for the input! I came to a similar conclusion, although opening the file can also be memory intensive. In the new implementation I move that processing to Rust, and look forward to process the file in batch (although it won't be top priority, as I will focus on feature parity first).

The software look at the number of channels and don't really care if both are equals. So I am not really surprised of that behavior.

May I know the length and size of your audio file for reference please? It will help me for design choices when I focus on that optimization.

[makkura]

I have a few of them, here's info on two of them I have on hand.
I've helping a friend get some visualizations over his podcasts to get them on YouTube.

• File1: mp3, size 91.5MB, duration 1:34:21, channels: 2 (stereo), 44.1khz
• File2: mp3, size 108MB, duration 1:51:28, channels: 2 (stereo), 44.1khz

Converting them to mono via:
sox file1.mp3 file1_mono.mp3 channels 1
If it takes an average of the two or chooses one really doesn't matter since the channels are identical.

• File1 Mono: mp3, size 45.3MB, duration: 1:34:21, channels: 1 (mono), 44.1khz
• File2 Mono: mp3, size 53.5MB, duation: 1:51:28, channels: 1 (mono), 44.1khz
  This also strips some of the meta data such as file description and cover art.