dantarbill

iZotope RX! (Standard is fine. You don't need the uber expensive Advanced edition.) It will seem like an expensive way to solve a limited problem, but after you have it, you'll wonder how you did without it. Gates can work too...but there's a lot of work involved in getting it dialed in right...and it doesn't deal with the veil of noise under the signal.

I've checked and rechecked... Any settings I make in "Selection after single split:" do NOT change the default behavior. It always acts as if I have "None" selected as the default behavior. Same is (was) true for the "Default Fade-In Curve>" and "Default Fade-Out Curve>". Ah HA!! I found it! The problem was that I had "Auto Crossfade" selected. That caused what I'll consider unintuitive behavior where it applied the Crossfade defaults when I split. I'm not sure if I had changed the "Auto Crossfade" selection or that behavior had changed with the new update...but I'm back in business.

Sorry...you're right. It's just S for Split and K for clip mute.

What I'm saying is that the config setting is getting ignored by 2023.09. On my system, there's currently no way to change the default behavior of Split or the Crossfade behavior.

I'm not sure if some default settings got changed with the 2023.09 update, but I'm seeing new and unwanted behavior... When I split a track (with "S"), typically the left side of the split is selected. So, if I subsequently hit "K" to mute the selected track portion, it mutes to the left. Now, it seems that neither is selected, so you have to explicitly select one side or the other. Also, the default crossfade (Options/Crossfade Type>Default Fade-In/Out Curve settings seem to now be completely ignored. What happened and how do I fix it? (I just checked Preferencess/Customization/Editing/Clips Selection after single split:. It's set to "Left Portion (default)". This strongly suggests that something in 2023.09 got broke or regressed.)

>...these days nobody should be using 44.1 or MP3 files. Sorry...still unapologetically using both all the time.

I think I might have found the sweet spot! So...the math looks like this...for a 48 kHz file... 2,147,483,647 (data length) / 3 (bytes per 24 bit sample) / 2 (for stereo) / 48,000 (samples/second) = 7,456.54 seconds / 60 (seconds/minute) = 124.28 minutes. Noting again that this is likely the data length rather than the file length, 2 hours and 4 minutes might not be the absolute max, but I don't currently know what order of magnitude the wav header is (which is variable anyway). I'm doubting that it's more than 288,000 bytes (which is one second of stereo 24/48 audio). The audio capture I have for today happens to be 2:03:45 in length, which should be under what I'm postulating as the "I'm giving up and converting" point. SonarWalk (Cakenar?) swallowed it without complaint! For my previous 44.1 kHz example, the math works out to 136.71 seconds max, which at 02:16:42 may be right around the hairy edge of the max. Have I answered my question?

Unfortunately, that's not the problem. The import bit depth is "Original". If not, it would, as you say, convert everything on import. Instead, it's only converting WaveLab created stereo 24/44.1 (or 24/48) files that are longer than some value that's more than somewhere over like an hour and a half, but I don't know what that critical point is yet. Thus the question. That critical length is likely to be file size based rather than time/length based since .w64 was partly an effort to sidestep a 32 bit file length (or data length?) descriptor in the original wav file header chunk spec. Hmm...the max unsigned 32 bit integer is 4,294,967,295. What if WaveLab is representing that as a signed integer? Then that would be more like 2,147,483,647. Maybe that's it...because...in the case above...it's less than the resulting file size. Cake dev's? Comments?

A 24bit 44.1 kHz stereo wav file that’s 2 hours 16 minutes and 42 seconds long (2,170,460,864 bytes) from a QSC TouchMix-30 will drop into a 24/44.1 Sonar session without incident. A stereo file built from QSC mono tracks of the same length and saved as 24/44.1 stereo in WaveLab, ends up with a slightly smaller file size (2,170,460,228 bytes)…but it will get converted on import to Sonar as to a .w64 format (2,893,950,960 bytes). I’ve figured out that trimming the end of such files or cutting them into two chunks sidesteps the issue. However, I like to know what Sonar is looking for in order to make its decision to convert to w64? What exact file length or audio length triggers this?

...anyone else care to weigh in on this?

I totally get that video is not Cake's forte...however. Since it has video support (to a point) what would be the process to get a video that starts here, ends there and has rendered audio? I'm not looking for fades or dissolves or anything even slightly involved. The "real video editor" thing comes later.

CakeSonarLab user since DOS 2.whatever. Complete video noob. I've imported an MP4 video into Cake 2022.11, along with stereo audio from a Tascam DR-40. The audio from the MP4 gets dumped to it's own stereo audio track, which is muted in favor of the DR-40 capture, which has been jam sync'd to the MP4 video/audio. I've marked where I want the video to start and end. Everything's happy so far. In my typical export/render, I'll select all tracks and select the section between my start and end markers. File/Export/Audio etc. My thought would be that export to video would be the same process right? Apparently not, since File/Export/Video just gives you the entire video you started with (not just from Start to End) without any audio. What is the actual process here?

I've found the "secret sauce". The problem was importing 32 bit files into a 24 bit project. However, QSC has a TouchMix Utility to help with track import. One of the options I hadn't noticed before was the option to quantize the tracks down from 32 bits to 24 bits while it's doing the transfer. With 24 bit tracks in had, Cakewalk is happy enough to accept the files without another copy.

Hmm...I tried that, with the same results I was getting before. The difference might be that I'm importing into a project with the audio driver recording at 24 bits, but I'm pulling in 32 bit files (with matching sample rates of 44.1 kHz). The sizes of the original and copied files are slightly different (3,380 bytes). That could be because Cakewalk isn't just doing a OS level file copy. It likely that it's also rewriting the .wav file header with some data that wasn't there before.

With the drag import it still creates a copy (<filename> (n).wav). Moreover...even if I unselect "Copy audio..." on import...it still copies.