Hi all, a couple of pieces of housekeeping before I dive in here:
Using Audacity v3.4.2 on Linux Mint 22 on a third-gen i7 w/ 32GB RAM
I have a Zoom H6 recording device
I had a party where I recorded a bunch of the DJ sets on the Zoom H6 recorder, on a SD card. I hooked up the recorder, pulled the WAV files onto my Linux Mint machine and loaded up the files into the version of audacity that comes with this distro. When I try to import the files just Audio, it comes up as single channel but the whole waveform is just blank, as if nothing imported at all.
The files are 2-channel 48kHz 24 bit PCM, and when I try to import them as Raw to those specs, I see waveforms but it’s all just straight noise.
I can load the files just fine in Celluloid and VLC and can hear everything just fine. The codec information in VLC shows the following:
CODEC: PCM S24 LE (s24l)
Type: Audio
Channels: Stereo
Sample rate: 48000 Hz
Bits per sample: 32
I even tried it as 32bits as per the last line there, and same thing - just harsh noise.
I did a bunch of searching and all I could find was exporting it as raw but that obviously didn’t seem to work. Anybody have any ideas what could be going on here? Suggestions or things I could look at?
Yeah, the problem isn’t from the H6 side of things - it recorded just fine. I had RCA Rec Outs to the XLR ins on the H6, everything looked fine on the meters, and like I said I can listen to them just fine in VLC or Celluloid, sound is just fine.
I worked around it by using FFMPEG commandline to convert the WAVs to typical CD quality (16bit 44.1KHz) and that seemed to import fine to Audacity, but I’d really like to know why the raw data off the H6 wasn’t working, as I’d like to be able to work with them at full freq/bitrate rather than have to downscale them for my lossless quality.
16/44.1 is generally better than human hearing so it should be fine. And if this was a vinyl DJ set, then CD quality is WAY better than analog vinyl.
You might try “converting” them to 24/48. Or convert them to 24/96, and then back to 24/48, or whatever you want.
I have no idea why this is happening… Regular WAV files are usually “foolproof”.
It could be the offset or bit depth.
You say they are 24-bits but VLC says 24-bits and 32-bits, which doesn’t make sense…
The offset of a normal WAV file is 44 bytes. That’s where the header ends and the audio begins. If the byte-order is wrong the bytes will be scrambled and re-assembled incorrectly. There are 8-bits in a byte so with a 24-bit file an offset of 0, 1, or 2 should work (or 44, 45, or 46). If you start around zero, the header will be converted to sound and you’ll get a glitch at the beginning but you can edit it out.
With 32-bits you can try 0, 1, 2, or 3. But I don’t think it’s 32-bits.
The left & right channel data are alternated so the wrong offset can also cause left & right to be swapped.
They’re commercial adapter cables. Again, you’re chasing a red herring here - I am able to listen to the files perfectly fine in other softwares, so the H6 recorded everything perfectly. The problem is that the files are not being read properly by Audacity.
Here’s what I got from one of the files:
General
Complete name : ZOOM0003_Tr12.WAV
Format : Wave
Format settings : PcmWaveformat
File size : 2.00 GiB
Duration : 2 h 4 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s
Producer : ZOOM Handy Recorder H6
Encoded date : 2024-08-10 15:49:41
Encoding settings : A=PCM,F=48000,W=24,M=stereo,T=ZOOM Handy Recorder H6
Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 4 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.00 GiB (100%)
The show that I pulled them from was a pretty big one so they’re all in the 1+GB realm. Give me a few hours though, I can record another quicker clip a bit later
I think it’s just the offset but I don’t know why it’s “wrong” when you try to open it in Audacity.
So try raw data with an offset of 44, 45, and 46 and one of those should work. (Probably not 44, since that’s what it should be expecting).
If that doesn’t work you can try both Little-endian and Big-endian. “Regular” WAV files are Little-endian, but not all, are and that’s another way for the bytes to get re-assembled incorrectly.
All of your numbers agree with 24/48 stereo…
48kHz x 24bits x 2 channels = 2304 kbps.
And 2304/8 is 288 kB per second and that works-out to 2GB for 2 hours.
There is a Common New Detective Failure: “It can’t possibly be this, so we’re not going to check it.”
Ten second Stereo WAV comes in at about 1.8MB. The forum limit is 2MB. I think I use 11 seconds in the forum test page, but lah. If you would please. I’m on the edge of my seat (and my knees are falling asleep).
I’ve been digging in the H6 Manual and they eventually get 95% of the way to explaining how they interconnect with outside music, instruments, or mixers.
I mean, I did check it, as I said, in VLC, and like I said before, and I can hear the recording just fine, so I know that the input signal is coming through to the H6. It has to be some form of encoding issue since re-encoding it through FFMPEG seemed to fix the issue.
So for testing, I grabbed a smaller sample file using largely all the same hardware (at least from the signal-to-the-H6 perspective) and everything seemed to be working okay, which is odd. Tried a few other tests with larger file size, and those all seem to be working okay too. So I’m going to chalk it up to a one-time encoding error on the H6 I guess?
Huzzah! This seemed to do it! Importing the raw data at offset of 46 with all the expected measures (48000, 24bit PCM, Stereo, no endianness) and the file imported exactly as I was hoping to see it! Thank you!
As I said in my other reply, I tried a few other recordings and they seemed to import to Audacity without needing to set the offset at all, just as I would expect it to through a typical drag-drop, so I think it’s something that just corrupted in the files from that one session, and listening through the files I’m wondering if someone unplugged the H6 before stopping the recording, and maybe it failed to properly encode the files? I’m really not sure, but this definitely seems to be an encoding error on the H6’s side.
There’s another trouble-shooting truism. If you didn’t find anything wrong, then the problem is still out there waiting for you.
So they should have maker and part numbers?
So 66% of the software you tried can play the files?
To give you an idea of the alarm bells: XLR cables work by comparing pins 2 and pins 3 inside the connector. Without proper connection management, you can get nothing, ghost performances, or a phase reversed performance.
But wait, there’s more. Did you turn off the Phantom Power in the H6? The H6 could be trying to make normal sound files out of normal sound mixed with 48 volt battery voltage. That shouldn’t be happening, but then you shouldn’t be having the problems you do.
Nothing I can find on the cables themselves - I think I just bought them from Long & McQuade so whatever their standard cables are, just two RCA-to-XLR cables. Have worked perfectly fine before and since the issue in question.
Correct. Also just launched the files in mplayer so it’s up to 75%. Add in the fact that ffmpeg was able to convert the files to fix the corruption, and it goes up to 80%.
At any rate, I was able to fix it with @DVDdoug 's offset solution, so yeah, looks like it was an encoding error with the file. My running theory is I think someone may have killed the device improperly and that may have had an effect on the file itself.
Pulled the batteries? The H6 is not a new recorder. Power/Hold is a slide switch on the Left. It’s not a convenient, momentary push button.
Somebody was trying for Safety-Hold and got Power briefly by accident? I have three recorders that do something similar. Power up the recorder, check it, start a recording, slide to Safety-Hold, and drop it in my pocket.
What doesn’t make ANY sense to me is that the files are OK in Celluloid and VLC. There’s something “different” in the way that Audacity is reading the files.
