Topic: Roland R-07 32-bit floating point!

[adrianb]

Just checked my files from last week’s gig and they’re a bit confusing. The main track is not clipping, but it is distorting, whilst the safety track is okay. Maybe the limiter kicking in but not doing a very good job. I don’t think these files will be any use for experimentation. Maybe I’ll stand in front of a load hi-fi when I get chance with limiters switched off.

[TheJez]

Just checked my files from last week’s gig and they’re a bit confusing. The main track is not clipping, but it is distorting, whilst the safety track is okay. Maybe the limiter kicking in but not doing a very good job. I don’t think these files will be any use for experimentation. Maybe I’ll stand in front of a load hi-fi when I get chance with limiters switched off.

When you mention distortion without clipping, my first thought would be 'overloading the analog gain stage'. (Of course I don't know your gear, but could this be a case of relatively sensitive mics combined with loud audio?)
Then maybe the analog path towards the safety track was protected from overloading by the -6/-12/-20dB attenuation.
In fact it may be interesting for experimentation, as the algorithm isn't specifically looking for clipping, but looking for 'louder parts where there is a relevant difference between the main track and the amplified safety track'. I expect that distorted parts of the main track would trigger the algorithm to use the safety track for those parts. However, practically, in this case the safety track is probably loud enough to be used as end result of your recording (unless there are very big dynamic differences in the recording).
So I'm open to and interested in testing this recording anyway, but I'd fully understand if you don't want to bother...

When you'll make a recording of your hifi, it doesn't necessarily needs to be set very loud (so you can keep the neighbors happy  ). Just put the mics close to the speaker and crank up the record level enough to make the main track clip!

[TheJez]

https://drive.proton.me/urls/AYQMC4TW4W#BdVrBJKwCWxu

4015gs -> SPDR 48/24 with safety (all 4 channels in 1 file)

I tend to run very conservatively so I haven't needed the safety track.

Thanks grawk! I've manually split the 4-track recording into two stereo files so my program can open them. I could of course make a special provision in the program to handle these kind of 4-track files. Is the safety file always stored like this in this particular device, or can you choose between 2xstereo or 1x4-track ?
And thanks for opening the can of soda (or whatever it is  ) at 17 seconds, as it adds some nice dynamics to the recording!
I will let you know there result, probably in the coming days...

[TheJez]

https://drive.proton.me/urls/AYQMC4TW4W#BdVrBJKwCWxu

4015gs -> SPDR 48/24 with safety (all 4 channels in 1 file)

I tend to run very conservatively so I haven't needed the safety track.

Thanks grawk! I've manually split the 4-track recording into two stereo files so my program can open them. I could of course make a special provision in the program to handle these kind of 4-track files. Is the safety file always stored like this in this particular device, or can you choose between 2xstereo or 1x4-track ?
And thanks for opening the can of soda (or whatever it is  ) at 17 seconds, as it adds some nice dynamics to the recording!
I will let you know there result, probably in the coming days...

I couldn't resist a quick check. The merged file still has quite some distortion leaking through from the main file. The main file is so distorted that there are many periods of consecutive clipping samples that are bigger than the window of 64 samples. In these situations it is not possible to determine the gain difference, and right now the algorithm uses the main track in that situation, which is plain stupid! I will need to update that. I guess I should use the lastly calculated gain instead, which was calculated not too long ago in the stream...
This proves the value of multiple test inputs! Thanks a bunch!

[grawk]

I was probably driving the preamps too hard. I was just recording music in my car from the radio.

[Rairun]

https://drive.proton.me/urls/AYQMC4TW4W#BdVrBJKwCWxu

4015gs -> SPDR 48/24 with safety (all 4 channels in 1 file)

I tend to run very conservatively so I haven't needed the safety track.

Thanks grawk! I've manually split the 4-track recording into two stereo files so my program can open them. I could of course make a special provision in the program to handle these kind of 4-track files. Is the safety file always stored like this in this particular device, or can you choose between 2xstereo or 1x4-track ?
And thanks for opening the can of soda (or whatever it is  ) at 17 seconds, as it adds some nice dynamics to the recording!
I will let you know there result, probably in the coming days...

I couldn't resist a quick check. The merged file still has quite some distortion leaking through from the main file. The main file is so distorted that there are many periods of consecutive clipping samples that are bigger than the window of 64 samples. In these situations it is not possible to determine the gain difference, and right now the algorithm uses the main track in that situation, which is plain stupid! I will need to update that. I guess I should use the lastly calculated gain instead, which was calculated not too long ago in the stream...
This proves the value of multiple test inputs! Thanks a bunch!

Very cool work you're doing!

Just out of curiosity: I'm assuming that you're calculating the gain difference that way out of an abundance of caution? Because I wouldn't expect gain to drift wildly - and where it does, I would think it'd be pretty transparent to most ears? Using the last calculated gain doesn't sound like it would cause any issues (especially compared to eyeballing it and doing it manually).

[TheJez]

Very cool work you're doing!

Thanks a lot! It's very interesting to work on, although my spare time to do this is limited. As I don't even own a recorder that produces a safety track, it is nice to see there is some interest in this project 

Just out of curiosity: I'm assuming that you're calculating the gain difference that way out of an abundance of caution? Because I wouldn't expect gain to drift wildly - and where it does, I would think it'd be pretty transparent to most ears? Using the last calculated gain doesn't sound like it would cause any issues (especially compared to eyeballing it and doing it manually).

I'd like to say: "Scientifically it was proven that this is the best way to do it" but that would be complete BS. It is more of a practical reason: Now I can jump to any position in the file, read the samples to fill the window and verify what the algorithm makes of it. It is a 'stateless algorithm', so to say, not depending on what's been happening before. Very handy for testing & debugging (especially as the preparation phase produces a list of locations where the main track is very likely clipping), but not so much for computing efficiency.
Maybe I will change the gain determination in a speed optimization phase, if there ever is going to be one. Or if my current way won't work well enough under certain conditions. We'll see! Work-in-progress...

[grawk]

https://drive.proton.me/urls/6HB94T3XG0#zN9fmeuxhO9i

The SPDR seems to have a permanent limiter, so it may not trigger your merge algorithm.

This should be a more realistic test

[TheJez]

https://drive.proton.me/urls/6HB94T3XG0#zN9fmeuxhO9i

The SPDR seems to have a permanent limiter, so it may not trigger your merge algorithm.

This should be a more realistic test

Thanks, I got the file! More realistic indeed  .
What makes you think there is a permanent limiter? Would that be active on main and/or safety track? If it is, then it's not doing a very good job  ...
See screenshot of a piece of the file. It shows 'classic' clipping at the top of the wave, and another kind of distortion, likely caused by analog stage overloading at the bottom. Either way, my algorithm should determine that there's a big difference here between main and amplified safety track, and should have faded in the safety track for this part...

[TheJez]

I do need to re-think the gain difference calculation... 
The recording I got from grawk contains periods with some very severe clipping, and during these periods the complete main track is rather damaged, even between the clipping samples. This results in very wrong calculated gain difference for some time. (E.g. factor ~12 instead of the expected factor ~7.78)
The algorithm does nicely conclude to use the safety track for these parts, but is using the incorrect gain to amplify the safety track, which will result in undesired behavior of the merged track...
Work in progress!! I think I might be heading to some running average, determined over periods where there is no clipping or clipping-related artifacts. (But how to determine that? I need a gain to amplify the safety track so I can compare main and safety to see if there are such artifacts... I might run in a chicken/egg situation here...)

[grawk]

What about an option of specifying the safety margin and whenever you detect clipping just replace it with the safety track + that fixed difference?

[TheJez]

What about an option of specifying the safety margin and whenever you detect clipping just replace it with the safety track + that fixed difference?

I really don't want the user to have to specify anything, especially since the user will not know the difference (in dB) exactly. When you e.g. select -12dB difference in your recorder, you'll get something like -12.023 or -11.984 or whatever, but certianly not 12.000000dB. And there will be different offsets for left and right channel and different offsets depending on temperature... It's not just for fun that SD patented mechanisms to deal with such variations, and I'm sure all other multi-ADC recorders will do similar smarts things too to combine the output of the ADC's. If the difference used to amplify the safety tracks deviates too much from 'reality', it might introduce audible artifacts around switching moments, which is what I'd really like to prevent. The gradual cross-fade between main and safety tracks already helps a lot there, but still I'd like to calculate the difference as accurately as possible.

[TheJez]

I've come up with an algorithm that determines a kind of 'average factor' for left and right in blocks of 1 minute of audio. Here's the result of Grawk's realistic sample of 4 minutes of a SPDR recorder:

=== Block  0  AvgAfterCleanupLeft= 7.78647  ( -17.8268 dB ) AvgAfterCleanupRight= 7.8069  ( -17.8496 dB)
=== Block  1  AvgAfterCleanupLeft= 7.78781  ( -17.8283 dB ) AvgAfterCleanupRight= 7.80856  ( -17.8514 dB)
=== Block  2  AvgAfterCleanupLeft= 7.79205  ( -17.833 dB ) AvgAfterCleanupRight= 7.80805  ( -17.8509 dB)
=== Block  3  AvgAfterCleanupLeft= 7.7921  ( -17.8331 dB ) AvgAfterCleanupRight= 7.80762  ( -17.8504 dB)

The algorithm works like this:
1. Read 1 minute of audio from main and safety track
2. Go through each 'frame' (= set of left/right main sample and left/right safety sample). Process left and right separately in the next steps
3. If both main & safety samples are positive or both are negative, and if both have 'substantial magnitude' (> -80dBFS, to prevent using very noisy samples) and if neither is 'too loud' (< -3dBFS, to prevent using clipping samples and damaged samples from analog overloading):
  - Calculate factor main/safety. This is 'the factor' for this single set of samples
  - Truncate the factor to 4 digits behind the decimal separator.
  - Put the value in a map, counting the number of occurences per value
4. Then, using the value that occured most in the minute of audio:
  - Calculate a weighted average of all values in the map that are within 1% of the value that occured most. (Using 'value * times of occurence' of all map entries within that 1% window) This will be 'the factor' for this channel for this minute!
5. Process next minute of audio

I'm sure there will be better and more efficient ways to achieve this, but I think this should result in a reasonably accurate factor between main and safety track for that minute of audio.

Next, I can calculate 'the factor' for any position within the file by doing linear interpolation of the 'factor per minute'. I'm curious what the results will be of this, but first I need to mow the lawn, hopefully for the last time this year before the winter kicks in 

[TheJez]

Yes! I'm perfectly happy with the new gain determination algorithm ! The difference between main and amplified safety track is now much smaller in non-clipping parts, making the clipping/distorted parts stand out perfectly. I noticed that the clipping recording from the SPDR device get quite some 'dc offset' in the period directly after the clipping event which gradually declines back to 0. These offsets ruined my previous window-by-window based gain algorithm but obviously the 'minute-based algorithm' rejects such parts from participating in the gain calculation.

I'm not sure where to go from here. The program is rather slow (~33% of realtime, so 30 minutes of audio takes ~10 minutes processing) and there is very much room for speed improvements, but I'm not sure if it's worth the effort... It's also not very monkey-proof. One needs to press the buttons in the right order, otherwise it may crash 
Would anybody be interested in getting this program at all? It's Windows-only at the moment...

[adrianb]

I’m quite in awe of what TheJez has done here. I’ve just been listening to the merged file of my clipping main track and safety track and it’s seamless.

Although I have just acquired a Zoom H1 XLR 32-bit recorder the Roland R-07 will remain my stealth recorder of choice. The form factor is great, I can even blag it’s an mp3 player, and the 3.1v of PIP voltage is just enough to power my Church Audio and DPA mics. I know many will say it’s not, but I have never had an issue. I tend not to use a battery box these days just for added simplicity.

I’m guessing I’m the perfect person to try and utilise the program, but given the increasing number of 32-bit recorders appearing it might be a market of one!