now this is an old issue, but I wanted to mention it, since I found it in the SQ and now also in my first recording from the CQ.
The WAV files from both consoles have some corrupted samples at the end. Most software will ignore this. For example, Audacity just doesn’t give a beep about it. However, when you want to compress your recordings using FLAC for loss-less archiving, you get this:
I was annoyed by this enough to write a hacky script that works on Linux (and maybe other OSses) that first processes the WAV files using ffmpeg which will actually complain about the same thing but then tolerate it, and then apply flac to them: ah-sq-hacks/sq-wav2flac.sh at main · DrNI/ah-sq-hacks · GitHub
ffmpeg says:
[pcm_s24le @ 0x55d6b13ba580] Invalid PCM packet, data has size 2 but at least a size of 3 was expected
Error while decoding stream #0:0: Invalid data found when processing input
Not really a feature request, but rather asking for a bug fix.
We’ve tried, and failed, to reproduce what you’re getting here.
Could you please contact us via support.allen-heath.com with more detail on the process you’re using to convert to flac and the corrupted samples?
I need to investigate into this a little more myself. Perhaps there might even be an issue with different “ideas” about FAT32/VAT in my old Kubuntu 18.04 vs. copying the files using a Windows system. For me and my system, in all cases of using the SQ or CQ recorder, the phenomenon is present.
So, finally getting back on the issue. I did a 10sec test recording on a CQ with the multitrack. Then I copied the file from the SD card using a Windows 10 box to rule out some different funny understandings of using FAT32 between the usual Linux systems I use and Windows. Copying the files to my Linux box via a network share…
… resulted in the described issue, still: “got partial sample”.
A tiny difference is that now that I have upgraded my Linux-based computers, flac doesn’t pretend to complete on the file anymore.