Hi, back in early 2019 we ran into some issues regarding the upload of 32-bit WAV audio.
Apparently this issue is still present in the current version of audiotool.
The issue arises when a user specifically uploads "WAV (Microsoft) 32-bit Float PCM" to Audiotool Cloud.
The files are accepted by Probe and can be manipulated without issue, however once exported to the Audiotool Cloud and fetched from the sample browser, the sample contains no audio. According to @mbelow back in jan. 2019, "the app can handle it but the server process that creates the mixdown fails".
This excerpt from the error message we got back then (Only @apollo got this error, I never did) might be useful to look at:
com.audiotool.next.bakery.BakeryException: java.lang.IllegalArgumentException: No reading method for [WavFile buffer:43k, compression:3, numChannels:1, sampleRate:44100, bytesPerSecond:176400, blockAlign:4, bitsPerChannel:32, dataOffset:44, numFrames:11127, dataOffset:44] - mixdown failed
I understand that 32-bit WAV is overkill for this purpose but I would very much like to have a warning message next time I forget to downsample and try to upload an unsupported format. Every time I forget, I only discover this error after I've already spent the time cutting, naming and uploading every piece of the sample :/
Could we have a warning message related to this in the near future?
Comments (11)
I guess you're referring to https://www.audiotool.com/board/bug_reports/probe_sample_uploading
I could have sworn there was a discussion about that issue in the Bug board. But I cannot find it anymore. So I don't know the current status.
I think this was the mentioned discussion: https://www.audiotool.com/board/feature_requests/does_probe_not_support
yeah, that was probably the same issue
Alright, thanks! Would be interesting to see if this can be reproduced. For reference, the issue arises when I export 32-bit WAV from Audacity on Windows 10.
yes, team@ audiotool.com?
No, the error was of old when we tried to publish a draft containing 24-bit samples. The track would not render when we tried to publish. My memory was a bit shoddy when I wrote this post it seems. I will test this once more to make sure that it was not a single case.
Ah, I hadn't experienced it before and made a presumption.
The strange thing is that I uploaded many samples before and after without issues, none of which were 32-bit. This one problematic sample happened to be 32-bit and all the selections I uploaded ended up being zero length. I'll still test this once more just to be certain, I apologize for not making sure it was reproducible :)
After 3AM CET probe has also started giving me "UPLOAD_SAMPLE request failed", but so far that has seemed unrelated to the zero length issue. Currently having issues exporting samples to the Cloud.
UPLOAD_SAMPLE error was experienced between 02:50 - 03:08 and 05:50 - 06:08 CET today. Tried every minute or so and tested across multiple browsers and computers this time. Only from one IP address but I still find this strange as it seems to be predictable. Will keep an eye open for this in the following days.
I seem to have forgotten that all the other samples I had worked with today were recorded internally through the live recording feature and not uploaded from file as I previously stated. However, the samples I have uploaded for testing this last hour have been zero length regardless of format (32/24/16-bit) and whether I received an error during the upload process. You are probably right about this not being related to what I outlined in the bug report.
Regardless of whether upload fails or not, the samples that show up in my assets are zero length. I have been unable to upload any playable samples for about an hour, does the failed request mean that it times out during the upload process?
Everything seems to finally work again, including 32-bit wav files. Sorry for the confusion! Thanks for the help, you may close this bug report.