I did get another instance of the unclean file splits issue. So it's sporadic.
(issue being occasionally getting the the tiniest smidgeon of ultra-high-DB-distortion, <.001s)
I'm really sorry to hear about your issues. I haven't used my FR-AV2 that much and never experienced the same issues as you. This really sounds like a couple of bytes of non-audio data being interpreted as floating point audio data, resulting in 'random sample values'.
I think I asked before, but I'm not sure about the answer, so I just ask again: What editor (and what version) are you using, and did you already try to open the same original (as in unmodified) file with another editor? Would you be willing and able to share such a faulty file so others can have a look at it? (I'd be happy to give it a try)
It seems that FR-AV2 creates a load of markers at 00:00:00.000 in each file, and maybe some editors won't deal with that properly under certain conditions. (Just speculating... I've seen audio processing software specifically stating they can't handle wav files with more than 'x' markers in it...)
It's definitely an issue with the AV2 and I'm pretty (but not 100%) sure there is a tiny bit of actual audio loss along with it. The issue is visible in both Reaper and Audacity, and if it had anything to do with the DAW I'd almost certainly see it across all my split files, not just some of them, as with this run. I'll DM you the raw file.
Since this is a hobby it's like, annoying, but man, if this occurred with a professional shoot, I'd be livid.
Thanks Kyle for providing the file for analysis.
My initial thoughts were right: This is 'random data' being interpreted as sample data. In fact it's not really random data, but the iXML structure written at the end of the file. This is basically a bunch of ASCII characters containing information about the recording, see attached image '01. Kyle data.png'.
When looking at the structure of your WAV file, I noticed it consists of five parts aka 'chunks' (see attached '02. Kyle chunks.png'):
Chunk 0: The 'bext' chunk, never mind
Chunk 1: The cue points chunk, containing 99 cue points
Chunk 2: The list chunk, containing 99 entries
Chunk 3: The fmt chunk, describing the format (sample rate, #channels etc) of the samples
Chunk 4: The data chunk, containing the actual samples. The iXML data at the end is part of this chunk, so will be interpreted by an editor or player as sample data.
When comparing this against one of my own recordings with the Tascam,
I see a sixth chunk at the end, which is the iXML chunk! So the same iXML data is there at the end, but it resides in its own chunk and not in the 'data chunk'. Hence editors will not try to interpret this iXML data as sample data.
So is this a bug? Hell yeah. As it happens sometimes, and not all of the time, I guess this is what they'd call a 'race condition'. Likely two threads of software processing are doing stuff in parallel (e.g. writing the iXML data at the end and then updating the header info about the new sixth chunk in 'the current file' while the other is creating the next file and changing the definition of 'current file' from previous file to new file). Almost always one thread finishes before the other, but occasionally the order of actions reverses, so the software is thinking it is writing to the old file while in fact it is already writing to the new file. Or something like that. I know from experience that multithreading software development can be challenging and it is easy to make errors that just occasionally occur and are difficult to find.
Unfortunately we can't seem to switch off the iXML writing, so that's not an option to prevent this problem from occuring. Just some hints:
- Make sure you run the latest firmware (currently 1.03), as they might already have solved the bug.
- Make sure you format the SD-card in the device, using the devivce formatting routine. Don't format the card from your pc while it is connected to it
Oh, when I just cut off the iXML data using a HEX editor, the file loads just fine without the spikes at the end. I cannot tell/guarantee if there is audio missing or not, as we can't be sure about the effect of the software bug.
Maybe if you'd glue the fixed file and the next file together, you can see if the audio is seamless at the merging point.
