Topic: SafetyTrackMerger (Windows + MacOS)

[TheJez]

Hi all,
Over the past couple of weeks I've been developing a little piece of software that can be used to automatically merge the main track and safety track of recorders like the Roland R-07 and Lectrosonics SPDR.
For clipping and/or distorted parts due to overloading the input stage, the safety track will be used, for non-clipping parts the main track is used.
This mechanism assures that the (noisier) safety track is only used in parts where it is necessary and where the sound is loud anyway so the extra noise won't be an issue. In the quiet, non-clipping parts the less noisy main track is used. It basically does the same thing as the 'modern' 32-bit floating point multi-ADC recorders do, except that they do the merging in real time during recording, and this piece of software is doing it during post proccessing. The end result is the same: An undistorted 32-bit floating point output file 

The discussions leading to this program can be found here:
https://taperssection.com/index.php?topic=205959.0

The Windows-version v1.0.0 of the program can be found here:
https://drive.google.com/file/d/1S21uO4yTdT85gQfTy3ARWzKfkSwJQtZ7/view?usp=sharing
Just unzip and run the SafetyTrackMerger executable. The manual is present in the zip file, as well as attached to this post.

(I am working on a MacOS version of the program, but due to my lack of experience with MacOS software development I'm not sure if I will succeed...)

Please let me know about your experiences with this program, either good or bad 

A big thanks to the people providing audio files for testing and for encouraging me!

[TheJez]

For those who are interested in this program, but are not working on Windows: I managed to build and test a MacOS version of the program! The program should run on both intel and apple cpu's. It was built on MacOS 15, but should run on older version too.

Here's the download link:
https://drive.google.com/file/d/1-CTV_uaWjRspmsgSeM9gb077_kVModYC/view?usp=sharing

I'd be happy with any feedback...

For those running into security warnings from Gatekeeper: I was told that these commands help to allow to run the program:

sudo spctl --master-disable
sudo chmod -R 777 ***
xattr -d com.apple.quarantine ***
xattr -cr ***

*** = path to SafetyTrackMerger.app file

[joeldotc]

Going to be testing this out today. I taped Geordie Greep last night in montreal and intentionally set the levels a bit too high for the opener.  I believe there should be some clipping in the main set too, but I was more conservative with my levels for that set just in case.

I’ll let you know how it goes!

[TheJez]

Going to be testing this out today. I taped Geordie Greep last night in montreal and intentionally set the levels a bit too high for the opener.  I believe there should be some clipping in the main set too, but I was more conservative with my levels for that set just in case.

I’ll let you know how it goes!

This is great to hear! I’m looking forward for your report! Are using Windows or MacOS version?

[joeldotc]

It worked great! I was using the windows version.

I had a brief issue at first which was causing the ".merged" track to be limited to 2h20m or so, whereas the ".32bfp" files were 2h40m - after resetting the app it fixed that issue though. It worked quite quick on my 2018 Huawei Matebook! About 5 minutes in total for the entire 2h40m show!

Here’s a link to the recording!

http://www.dimeadozen.org/torrents-details.php?id=788146
https://archive.org/details/greep2025-02-05.ca14

[TheJez]

It worked great! I was using the windows version.

I had a brief issue at first which was causing the ".merged" track to be limited to 2h20m or so, whereas the ".32bfp" files were 2h40m - after resetting the app it fixed that issue though. It worked quite quick on my 2018 Huawei Matebook! About 5 minutes in total for the entire 2h40m show!

Here’s a link to the recording!

http://www.dimeadozen.org/torrents-details.php?id=788146
https://archive.org/details/greep2025-02-05.ca14

Thanks for your feedback! I will have a listen to the recording... Would it maybe be possible to zip and then share the *.log file here (or as PM), so I can have a look what the program has been doing?
I have no explanation why the result was cut short at first. I do know the program pads some silence to make the output a multitude of minutes and then adds another 128 samples at the end (both out of laziness of me as it simplified the software a bit), but it should never cut it short. Glad it worked out well on the next attempt.

[kuba e]

TheJez, thank you for your great program. I tried it, it's really beautifully done, tightened to the last detail. Working on Windows and Mac. And the manual is also perfect. I know it took a lot of work. Thank you very much for sharing it and also for discussing the theoretical side and how you developed the program. I think this is unique, I haven't seen something similar.

[TheJez]

TheJez, thank you for your great program. I tried it, it's really beautifully done, tightened to the last detail. Working on Windows and Mac. And the manual is also perfect. I know it took a lot of work. Thank you very much for sharing it and also for discussing the theoretical side and how you developed the program. I think this is unique, I haven't seen something similar.

Hi Kuba E, thank you for your kind words.  I'm indeed quite happy with the result myself  and I'm happy to see people are starting to try and use the program and appreciate it. The only thing I regret is that I didn't create the program years ago... And that I don't own a recorder that creates a safety track myself 

[EmRR]

Cool idea!

[heva]

Any chance to get the software on Linux as well?

[TheJez]

Any chance to get the software on Linux as well?

I'm sorry, I don't have the time at the moment to port it to Linux too. Technically it would be possible, though, as all 3rd party libraries used are available for Linux.

[joeldotc]

Thanks for your feedback! I will have a listen to the recording... Would it maybe be possible to zip and then share the *.log file here (or as PM), so I can have a look what the program has been doing?
I have no explanation why the result was cut short at first. I do know the program pads some silence to make the output a multitude of minutes and then adds another 128 samples at the end (both out of laziness of me as it simplified the software a bit), but it should never cut it short. Glad it worked out well on the next attempt.

I’ll take a look at my PC when I get home today for that log file - I figure it would’ve been overwritten when redoing the processing, but I’ll let you know!

[TheJez]

Thanks for your feedback! I will have a listen to the recording... Would it maybe be possible to zip and then share the *.log file here (or as PM), so I can have a look what the program has been doing?
I have no explanation why the result was cut short at first. I do know the program pads some silence to make the output a multitude of minutes and then adds another 128 samples at the end (both out of laziness of me as it simplified the software a bit), but it should never cut it short. Glad it worked out well on the next attempt.

I’ll take a look at my PC when I get home today for that log file - I figure it would’ve been overwritten when redoing the processing, but I’ll let you know!

Yes, you're right, the 2nd run will have overwritten the initial log file. I was just curious what logging was produced for the successful run, so I'd really appreciate it if you can provide it. No hurries, though...
It's quite weird, as the program should do the exact same thing when it's fed the same input. There should be no 'randomness' in the program...

[joeldotc]

Here is that txt file! I removed the PC locations from the top of the file, but otherwise that's exactly what the program output to me!

[TheJez]

Here is that txt file! I removed the PC locations from the top of the file, but otherwise that's exactly what the program output to me!

Thanks for sharing! I see the program indeed did some combining in a few parts of the show, mostly on the left channel. E.g. around 00:05 minutes into the show, 01:09, 01:28-01:31, 01:38, 01:40 and some parts towards the end. In the other parts there was no need to use samples from the safety track.
I do notice a strange jump in the delta between left channel main and safety track around the 124th minute! Before that, the left channel delta between main and safety was ~10.33dB, after that it suddenly became ~11.57dB. Remarkable! Fortunately the program very gradually follows the changes in delta, so it won't be bothered by such a jump.

121   3.2877 (= 10.3378dB)   3.8856 (= 11.7891dB)
 122   3.2856 (= 10.3323dB)   3.8851 (= 11.7880dB)
 123   3.2878 (= 10.3381dB)   3.8848 (= 11.7873dB)
 124   3.2848 (= 10.3303dB)   3.8850 (= 11.7878dB)
 125   3.7926 (= 11.5787dB)   3.8869 (= 11.7920dB)
 126   3.7923 (= 11.5781dB)   3.8850 (= 11.7879dB)
 127   3.7917 (= 11.5766dB)   3.8843 (= 11.7862dB)
 128   3.7918 (= 11.5768dB)   3.8837 (= 11.7849dB)

Also I see some error in the position reporting in the log file, when converting sample position to timestamp in hh:mm:ss.zzzzzz:

00:29:45.277666       85693328      Left Fade Out Safety                         
00:52:4338.42959244294968283      151871539       Left Fade In Safety                         
00:52:4338.42959274294967950      151871667      Left Fade Out Safety

I think this will be a logging-issue only and won't affect the inner workings or output of the program...

Thanks again for sharing! That's much appreciated!

[joeldotc]

I do notice a strange jump in the delta between left channel main and safety track around the 124th minute! Before that, the left channel delta between main and safety was ~10.33dB, after that it suddenly became ~11.57dB. Remarkable! Fortunately the program very gradually follows the changes in delta, so it won't be bothered by such a jump.

Interesting! That is probably exactly where a track split was made by the recorder since it reached its 2 GB max file at around the 2h4m mark! I wonder why it would produce that difference though!

Makes sense that the combining only occurred in the first part of the recording, because I adjusted my levels after the first song since I noticed it was clipping and wasn’t sure how the program would do.

I’ll probably keep my levels high and let clipping happen in the future since this software you’ve made seems to work marvellously!

[TheJez]

I do notice a strange jump in the delta between left channel main and safety track around the 124th minute! Before that, the left channel delta between main and safety was ~10.33dB, after that it suddenly became ~11.57dB. Remarkable! Fortunately the program very gradually follows the changes in delta, so it won't be bothered by such a jump.

Interesting! That is probably exactly where a track split was made by the recorder since it reached its 2 GB max file at around the 2h4m mark! I wonder why it would produce that difference though!

Makes sense that the combining only occurred in the first part of the recording, because I adjusted my levels after the first song since I noticed it was clipping and wasn’t sure how the program would do.

I’ll probably keep my levels high and let clipping happen in the future since this software you’ve made seems to work marvellously!

Hi Joel, indeed remarkable that it's at the track split. I see no reason for the recorder to fiddle with the gain when splitting the track. It's especially remarkable that it's only on one channel!
It's a Roland R07 recording, right? Maybe, if you have the time and ability, you could load the first part and the second part into a DAW and do some amplitude statistics just before and just after the split to see if that confirms a difference. I cannot say if the safety track got less loud or if the main track got louder, as the program only calculates (and the compensates for) the difference in dB.
Thanks a bunch!

[joeldotc]

Maybe, if you have the time and ability, you could load the first part and the second part into a DAW and do some amplitude statistics just before and just after the split to see if that confirms a difference. I cannot say if the safety track got less loud or if the main track got louder, as the program only calculates (and the compensates for) the difference in dB.
Thanks a bunch!

Finally got around to this! I've attached two screenshots here:

- one showing amplitude stats for the entire files of all four recordings
- one showing amplitude stats for 15 seconds before/after the track split for each recording, respectively

It looks like the 11.58 dB difference is constant, so I wonder why the program isnt showing that 

I was thinking maybe I merged my two files incorrectly before putting the full thing through your software, but I don't notice any weirdness in the merged track around the 2h4m mark, so no clue what it could be!

Let me know if you have any questions at all. I can also send you the raw files if you'd like to experiment with them yourself

[TheJez]

Finally got around to this! I've attached two screenshots here:
Let me know if you have any questions at all. I can also send you the raw files if you'd like to experiment with them yourself

Hi Joel, thanks for the screenshots. I've had a very busy week, so it took a little while to have a look. It's hard to draw any conclusions from the screenshots. My program doesn't really care about the amplitude values of the tracks themselves, it only cares about the difference between the two and tries to avoid clipping parts to pollute the delta determination. I'd really like to take you up on your offer to provide the raw files. It would be very interesting to try to find out what's happening here... Please PM on how I can obtain them... Thanks a bunch!

[TheJez]

Finally got around to this! I've attached two screenshots here:
Let me know if you have any questions at all. I can also send you the raw files if you'd like to experiment with them yourself

Hi Joel, thanks for the screenshots. I've had a very busy week, so it took a little while to have a look. It's hard to draw any conclusions from the screenshots. My program doesn't really care about the amplitude values of the tracks themselves, it only cares about the difference between the two and tries to avoid clipping parts to pollute the delta determination. I'd really like to take you up on your offer to provide the raw files. It would be very interesting to try to find out what's happening here... Please PM on how I can obtain them... Thanks a bunch!

FYI: Joeldotc very kindly provided the original raw files straight from the recorder. I did some testing on these and was not able to reproduce the issue. Hence our combined conclusion was that probably some unintentional processing was done on the files before they were being fed to the SafetyTrackMerger program, causing a small amplitude change on one of the channels in one of the input files.
Hence a warning is given: The main and safety wav files shall not be processed in any way before feeding them to the program! Only in case the recording was split over multiple files (e.g. due to 2GB splits), please merge the parts together so there is just one main file and one safety file, and then feed these to the program.
Cheers!

[TheJez]

Also I see some error in the position reporting in the log file, when converting sample position to timestamp in hh:mm:ss.zzzzzz:

00:29:45.277666       85693328      Left Fade Out Safety                         
00:52:4338.42959244294968283      151871539       Left Fade In Safety                         
00:52:4338.42959274294967950      151871667      Left Fade Out Safety

I think this will be a logging-issue only and won't affect the inner workings or output of the program...

The issue with incorrect timestamps in the log file has been resolved in version 1.0.1 of the Windows-version of the program. It was an integer overflow issue when converting sample number to hh:mm:ss.zzzzzz. To upgrade, just replace the executable with the one attached to this post. As this is a fix of a cosmetic issue only, I'm not planning to create a MacOS executable of 1.0.1...