wav to w64 conversion on import

[dantarbill]

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?

Edited April 23, 2023 by dantarbill
nome

[msmcleod]

Check your import bit depth within Preferences->File->Audio Data.  If it's set to 64, then it'll be converting everything to 64 bit on import.  IIRC, the default setting is "original".
 

[dantarbill]

16 hours ago, msmcleod said:

Check your import bit depth within Preferences->File->Audio Data.  If it's set to 64, then it'll be converting everything to 64 bit on import.  IIRC, the default setting is "original".
 

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?

[dantarbill]

51 minutes ago, dantarbill said:

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?

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?

Edited April 24, 2023 by dantarbill