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!