Wave Copilot - A WAV file utility for production sound (Mac, Windows & Linux)

[callou]

The workflow i'd like is to have poly's for each takes of only the tx's on board without any tracks from the main recorder, so i can deliver a " main recorder " folder and a "backup" folder for each day.

it could be name "match Reference+combine" ..

 Much simpler to explain to post and for us to manage at wrap.

And when  doing post we can auto conform both folder quicker without having any double material..

 

it's basicly  the Sd-utility from Sound devices worklow ;but for all brands..

 

you could had an option to the track replace to ignore all tracks from the main recorder for all takes ...but a dedicated process seems more straigt forward to me.

 

[Matt Nantel]

8 minutes ago, callou said:

The workflow i'd like is to have poly's for each takes of only the tx's on board without any tracks from the main recorder, so i can deliver a " main recorder " folder and a "backup" folder for each day.

it could be name "match Reference+combine" ..

 Much simpler to explain to post and for us to manage at wrap.

And when  doing post we can auto conform both folder quicker without having any double material..

 

it's basicly  the Sd-utility from Sound devices worklow ;but for all brands..

 

you could had an option to the track replace to ignore all tracks from the main recorder for all takes ...but a dedicated process seems more straigt forward to me.

 

This make sense. Now you can do it in 2 steps, but I will check on an option to make the poly wave automatically. 

[callou]

2 minutes ago, Matt Nantel said:

This make sense. Now you can do it in 2 steps, but I will check on an option to make the poly wave automatically. 

That's great!! looking forward to it!

Sorry wave agent , you served us well but time to enjoy retirement !

[inspire]

I tested the new silent channel warning feature with some real-world recordings, and in my case the current –80 dBFS threshold may be slightly too low for practical production sound use.

My “effectively silent” tracks are often closer to around –72 dBFS to –70 dBFS due to recorder/input noise floor, even when no microphone is connected or no useful signal is present.

Perhaps it could be useful to make the silence detection threshold user-adjustable in the future, depending on different recorder noise floors and workflows.

[Matt Nantel]

8 hours ago, inspire said:

I tested the new silent channel warning feature with some real-world recordings, and in my case the current –80 dBFS threshold may be slightly too low for practical production sound use.

My “effectively silent” tracks are often closer to around –72 dBFS to –70 dBFS due to recorder/input noise floor, even when no microphone is connected or no useful signal is present.

Perhaps it could be useful to make the silence detection threshold user-adjustable in the future, depending on different recorder noise floors and workflows.

Ok I will adjust that in the next release.

[inspire]

Thank you, that sounds great.

After doing a few more tests, I think the reason my “silent” tracks are measuring higher than –80 dBFS is probably because the input gain is still active even when no microphone is connected. In real production workflows, I suspect many users leave the gain settings unchanged rather than disabling or reducing them on unused channels.

For example, on the Sound Devices MixPre-6 II, lowering the gain is not just a quick front-panel adjustment — it usually means going deeper into the menu system. In practice, it is often easier and safer to simply leave the channel armed and keep recording, even if a microphone is temporarily disconnected or unused.

So the higher noise floor on otherwise “empty” tracks is probably quite normal in real-world use.

Also, I imagine that if the input gain were set even higher, the measured level of an otherwise “empty” channel could become significantly louder as well.

In practice, an unused production sound channel is often not truly silent in a digital sense, because the recorder is still capturing the preamp/input noise floor, especially when gain remains active on an unconnected input.

I think the current default value is probably still a sensible starting point, but making the threshold user-adjustable would likely be the best long-term solution, since different recorders, gain settings, and workflows can produce very different noise floors on otherwise unused channels.

It could also be useful to have a simple “Reset to Default” option, since users may experiment with extreme threshold values and later forget what they changed.

[The Documentary Sound Guy]

I'm going to be the Linux complainer and complain about what appears to be a packaging error.  Sorry, I know this is why Linux support gets dropped.

 

I get this error message: 

[358753:0514/223504.982259:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_Wave.Cag6QE0/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

 

I'm honestly not sure if this is my own misconfiguration for AppImages, but I suspect it's not, since the issues seems to be that it can't get root access to a directory in /tmp (directory does not exist, so the issue is that it can't be created by root).  I don't see why a user program would require root, but maybe it's just that I haven't set up AppImage sandboxing correctly?  This isn't usually my preferred form of executable...

Also ... I hate the way Chrome sneaks its way into everything.  I get that this is how cross-compatibility is made feasible in many cases, but I hate having to deal with the overhead of running a packaged browser, and having to trust a google product that is invisibly packaged from developers that have nothing to do with Google.

Anyway ... those are my Linux-whines ... thank you for making the effort to support Linux in the first place!  I hope the error message is useful along with my sour grapes.

[The Documentary Sound Guy]

BTW, the .deb version works just fine.

[inspire]

I did a small test this morning with the new silent channel detection feature.

I started with a 4-channel 32-bit float poly WAV file (MixPre-001.WAV). Three of the channels were effectively empty, but originally their noise floor was still above the current threshold.

To test the feature more clearly, I split the poly WAV into four mono files, then reduced the gain of the three empty channels significantly in iZotope RX (approximately –30 dB). After that, I combined the files back into a poly WAV using Wave Copilot.

When reopening the file in Wave Copilot, the software correctly detected the silent channels and displayed the warning icons/triangles as expected. So the feature appears to work very nicely.

(See attached screenshot.)

One thing I was wondering about for future workflow improvements:
after the silent channels are detected and flagged, is there currently a quick way to automatically exclude or ignore those channels during the reconform/combine process? Or would that perhaps be something worth considering in the future?

[Matt Nantel]

7 hours ago, The Documentary Sound Guy said:

I'm going to be the Linux complainer and complain about what appears to be a packaging error.  Sorry, I know this is why Linux support gets dropped.

 

I get this error message: 

[358753:0514/223504.982259:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_Wave.Cag6QE0/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

 

I'm honestly not sure if this is my own misconfiguration for AppImages, but I suspect it's not, since the issues seems to be that it can't get root access to a directory in /tmp (directory does not exist, so the issue is that it can't be created by root).  I don't see why a user program would require root, but maybe it's just that I haven't set up AppImage sandboxing correctly?  This isn't usually my preferred form of executable...

Also ... I hate the way Chrome sneaks its way into everything.  I get that this is how cross-compatibility is made feasible in many cases, but I hate having to deal with the overhead of running a packaged browser, and having to trust a google product that is invisibly packaged from developers that have nothing to do with Google.

Anyway ... those are my Linux-whines ... thank you for making the effort to support Linux in the first place!  I hope the error message is useful along with my sour grapes.

Hi, the immediate workaround about the error you are getting is to launch the current AppImage from the terminal with:

./Wave-Copilot-*.AppImage --no-sandbox

I've already patched the build config to pass --no-sandbox automatically, so the next release will just work without any workarounds needed.
 

On the Chromium/Electron point, completely fair criticism. It's the cost of cross-platform compatibility, and I appreciate you putting up with it. Thanks again for taking the time to write it up, and for the kind words about Linux support!

6 hours ago, inspire said:

I did a small test this morning with the new silent channel detection feature.

I started with a 4-channel 32-bit float poly WAV file (MixPre-001.WAV). Three of the channels were effectively empty, but originally their noise floor was still above the current threshold.

To test the feature more clearly, I split the poly WAV into four mono files, then reduced the gain of the three empty channels significantly in iZotope RX (approximately –30 dB). After that, I combined the files back into a poly WAV using Wave Copilot.

When reopening the file in Wave Copilot, the software correctly detected the silent channels and displayed the warning icons/triangles as expected. So the feature appears to work very nicely.

(See attached screenshot.)

One thing I was wondering about for future workflow improvements:
after the silent channels are detected and flagged, is there currently a quick way to automatically exclude or ignore those channels during the reconform/combine process? Or would that perhaps be something worth considering in the future?

For the moment, the is no way of excluding them automatically. You have to set them to "keep reference" one by one. I will think on how I could do this in the future. Thanks again for your input.

[inspire]

Thank you for the clarification.

That already helps a lot, because now I know I was not simply overlooking some hidden option or mouse action somewhere in the interface. Sometimes features already exist in software, but the user just does not immediately discover the workflow behind them.

For now, setting them to “keep reference” manually is perfectly understandable, and I appreciate that you are considering possible workflow improvements for the future.

Thanks again for the fast responses and active development.

[Matt Nantel]

On 5/13/2026 at 7:20 PM, callou said:

The workflow i'd like is to have poly's for each takes of only the tx's on board without any tracks from the main recorder, so i can deliver a " main recorder " folder and a "backup" folder for each day.

it could be name "match Reference+combine" ..

 Much simpler to explain to post and for us to manage at wrap.

And when  doing post we can auto conform both folder quicker without having any double material..

 

it's basicly  the Sd-utility from Sound devices worklow ;but for all brands..

 

you could had an option to the track replace to ignore all tracks from the main recorder for all takes ...but a dedicated process seems more straigt forward to me.

 

The new version (1.0.11) is out with the option to deliver a poly wav file with all your TX matching the main recorders files. This function is under the conform tab in the Match Reference by checking the Poly Wav Output checkbox. Wave Copilot will match your TX files with your main recorder's files base on the TC and will output a poly wav file with all your TX.

On 5/15/2026 at 1:17 AM, inspire said:

I did a small test this morning with the new silent channel detection feature.

I started with a 4-channel 32-bit float poly WAV file (MixPre-001.WAV). Three of the channels were effectively empty, but originally their noise floor was still above the current threshold.

To test the feature more clearly, I split the poly WAV into four mono files, then reduced the gain of the three empty channels significantly in iZotope RX (approximately –30 dB). After that, I combined the files back into a poly WAV using Wave Copilot.

When reopening the file in Wave Copilot, the software correctly detected the silent channels and displayed the warning icons/triangles as expected. So the feature appears to work very nicely.

(See attached screenshot.)

One thing I was wondering about for future workflow improvements:
after the silent channels are detected and flagged, is there currently a quick way to automatically exclude or ignore those channels during the reconform/combine process? Or would that perhaps be something worth considering in the future?

The new version (1.0.11) is out with a new threshold slider where you can decide which value you like for the silence track detector. You can also reset the track that has been detected and ignore them with a button that will reset them automatically to "Keep reference".

On 5/13/2026 at 11:18 AM, callou said:

just had a run with the demo , and everything looks greati just a few wish ; ability to drop folders to scan files would be great and also a 1 step  way  to conform on-board tx recordings to the the main recorder and combine them into poly files, ( like the Sound devices app does). really wish i have that for Zaxcom and wisy trabsmiter. ( As a sound mixer and a as a dial editor as much). Maybe i missed something but it seems like a  2 step process for now  (comform then combin) and something i ll be reluctant to do at wrap

You can now drop a folder in version 1.0.11.

[inspire]

The new threshold slider and “Keep reference” automation work very nicely in my tests. Thank you again for implementing this so quickly.

I think a possible future workflow enhancement could be an optional final step where already reviewed and confirmed silent channels could be automatically excluded/removed from the combine process.

In practice, production mixers usually already know which channels were intentionally unused or empty, and the Playback view also makes this visually quite easy to verify. So after manually reviewing the detected channels and confirming the threshold is correct, a small optional automation step at the end could make the workflow even faster.

Of course, the exact implementation is entirely up to you, but I think the current system already provides a very solid foundation for this kind of workflow.

[Derek H]

A small thing but could you make the fields where you enter a timecode address automatically add the colons? So that you can just punch in 8 digits and it comes out 00:00:00:00 with the :'s in place. Thank you.

[Matt Nantel]

8 hours ago, Derek H said:

A small thing but could you make the fields where you enter a timecode address automatically add the colons? So that you can just punch in 8 digits and it comes out 00:00:00:00 with the :'s in place. Thank you.

Yes, this will be in the next update.

[Derek H]

Great thank you!

 

Like the person above, I also vote for a mode that allows you to take multiple recordings, align them by timecode, fill any gaps with silence and output a poly WAV. Without necessarily requiring a reference file to match. 
 

I could have used this kind of thing the other day on a shoot where I wired up several pocket recorders on people going on a canoe trip. 4x separate recordings, no “primary” recording to match to. 
 

Thanks!

 Derek

 

[Matt Nantel]

7 hours ago, Derek H said:

Great thank you!

 

Like the person above, I also vote for a mode that allows you to take multiple recordings, align them by timecode, fill any gaps with silence and output a poly WAV. Without necessarily requiring a reference file to match. 
 

I could have used this kind of thing the other day on a shoot where I wired up several pocket recorders on people going on a canoe trip. 4x separate recordings, no “primary” recording to match to. 
 

Thanks!

 Derek

 

It is possible to do it with files as reference at this time in the version 1.0.11 but in the next version, it will be possible to do it with a CSV reference. So you could just generate the csv file with the sound report function and then assemble your poly wav without files to match and use the CSV instead. It will only required to have a start TC and end TC to work.

[Matt Nantel]

8 hours ago, Derek H said:

Great thank you!

 

Like the person above, I also vote for a mode that allows you to take multiple recordings, align them by timecode, fill any gaps with silence and output a poly WAV. Without necessarily requiring a reference file to match. 
 

I could have used this kind of thing the other day on a shoot where I wired up several pocket recorders on people going on a canoe trip. 4x separate recordings, no “primary” recording to match to. 
 

Thanks!

 Derek

 

Finally I decided to add this feature in the custom TC range in the conform section as well. This will be release in the next version.

[Derek H]

Thanks!

 

[Matt Nantel]

19 hours ago, Derek H said:

Great thank you!

 

Like the person above, I also vote for a mode that allows you to take multiple recordings, align them by timecode, fill any gaps with silence and output a poly WAV. Without necessarily requiring a reference file to match. 
 

I could have used this kind of thing the other day on a shoot where I wired up several pocket recorders on people going on a canoe trip. 4x separate recordings, no “primary” recording to match to. 
 

Thanks!

 Derek

 

The new version 1.0.12 is available. with your requested feature available. 

On 5/22/2026 at 1:09 AM, inspire said:

The new threshold slider and “Keep reference” automation work very nicely in my tests. Thank you again for implementing this so quickly.

I think a possible future workflow enhancement could be an optional final step where already reviewed and confirmed silent channels could be automatically excluded/removed from the combine process.

In practice, production mixers usually already know which channels were intentionally unused or empty, and the Playback view also makes this visually quite easy to verify. So after manually reviewing the detected channels and confirming the threshold is correct, a small optional automation step at the end could make the workflow even faster.

Of course, the exact implementation is entirely up to you, but I think the current system already provides a very solid foundation for this kind of workflow.

You can now remove silent tracks from the output poly wav files in the new version 1.0.12.

On 5/13/2026 at 7:20 PM, callou said:

The workflow i'd like is to have poly's for each takes of only the tx's on board without any tracks from the main recorder, so i can deliver a " main recorder " folder and a "backup" folder for each day.

it could be name "match Reference+combine" ..

 Much simpler to explain to post and for us to manage at wrap.

And when  doing post we can auto conform both folder quicker without having any double material..

 

it's basicly  the Sd-utility from Sound devices worklow ;but for all brands..

 

you could had an option to the track replace to ignore all tracks from the main recorder for all takes ...but a dedicated process seems more straigt forward to me.

 

You can now conform TX files without the need of reference files. This is possible with the CSV conform option of the match reference tab by selecting the poly wav output checkbox or by entering a start TC and end TC in the custom TC range section by selecting also the poly wav output checkbox. 

[inspire]

First of all, thank you again for the latest update. I tested the new “Remove silent tracks from output” feature and it works perfectly in my workflow.

I was also wondering if you might consider, at some point in the future, making the normalization target configurable as well, instead of only using a fixed normalization ceiling.

For example, some users may prefer:

• –1 dBFS
• –0.3 dBFS
• or other values depending on their workflow or delivery requirements.

This is not meant as a request to change the current default behavior — the current implementation already works very well — but simply as a possible future enhancement that could make the normalization feature even more flexible.

[Matt Nantel]

7 hours ago, inspire said:

First of all, thank you again for the latest update. I tested the new “Remove silent tracks from output” feature and it works perfectly in my workflow.

I was also wondering if you might consider, at some point in the future, making the normalization target configurable as well, instead of only using a fixed normalization ceiling.

For example, some users may prefer:

• –1 dBFS
• –0.3 dBFS
• or other values depending on their workflow or delivery requirements.

This is not meant as a request to change the current default behavior — the current implementation already works very well — but simply as a possible future enhancement that could make the normalization feature even more flexible.

Thanks for the suggestion, but this is a deliberate design choice rather than an oversight.

 

The normalization ceiling is a safety net against clipping, not a delivery target.  It's not meant to set your final loudness. For actual delivery requirements (broadcast, streaming, podcast specs), the right tool is a loudness-aware normalizer targeting a specific LUFS value, not a peak ceiling adjustment. If your workflow requires a specific peak level for a delivery spec, that's better handled in your DAW or a dedicated mastering tool where you control the full signal chain.

 

I appreciate you taking the time to share the idea. 

 

[inspire]

No worries, I can handle small modifications later with RX very well (Or with some DAW like Reaper). That would have saved me in some cases. I often have two ISO tracks (left and right) like Master. Thank you for the explanation!

[RsmithSound]

Just downloaded the trial. I'm having good luck with it so far. I think there is some room for quality-of-life improvements to the playback page, though these would not necessarily be as pressing as some other suggestions:

As it stands, the playhead behaves in an "insertion follows playback" style, where the playhead stops where playback stops. I would like to see a toggle to set the playhead to start from the same position every time.

It would be nice to navigate with the keyboard, perhaps with the J/K/L keys, or the arrow keys, or brackets.

It would be nice to have different solo mode options. The solo buttons all latch now. I would like an "X-OR" option where hitting solo on a new track cancels the solo of the previous track; only one track is in solo at a time. Like the playhead note, this would just be an additional option.

 

I see we can double-click to set faders to unity. Perhaps double-clicking in the pan field should set the panning to center.

I feel the urge to zoom in on a longer recording. Something to consider. And if you implemented that, I would recommend the ability to set a preference for window scrolling behaviors during playback. And maybe a modifier key to scroll left and right. I'd vote for the Shift key. 

These are all just "nice to have" ideas. I'm really loving the core functionality behind this. Great work!

[inspire]

@RsmithSound Good suggestions 😇
I don't know how easy it is to add this, but really nice suggestions.