PDA

View Full Version : RME's New digicheck record global



Warren
06-23-2006, 02:06 PM
Will Saw be able to import a 24track interleaved .wav file created in this way
If it help people with slow machines record long sessions that have no interuptions and you can still edit each track later. This just keeps getting better.:D

Or i'm I missing something? :eek:

Pedro Itriago
06-23-2006, 02:15 PM
Yeah, you're missing the fact that you can already do live reconding in saw

Warren
06-23-2006, 02:22 PM
And your missing the point! :rolleyes:
Can you say Redundancy :D

tomasino
06-23-2006, 02:38 PM
24 channel interleaved! That's whack.
I'm gonna guess no - but ya never know.

Bob never ceases to amaze.

Warren
06-23-2006, 02:50 PM
It seems you record it interleaved but can save it in a multi-file format, its beta and has at this point a bug or two but is in work.
and suposably if power is lost it does not result in loss of data.
We shall see when the smoke clears.


Warren

TotalSonic
06-23-2006, 04:07 PM
proprietary formatting + 1 gigantic file instead of many smaller ones =
greater possibility of really losing data to corruption and not having it as compatible (i.e. easily openable) on as many systems.

While I can see having an entire sessions files "grouped" together being a possible convenience , simply opening the folder containing the files in one of SAW's library views, click dragging to selecting the entries you want, and then shift-inserting them into the multitrack view does the exact same thing for you. So to me this multi file interleaving isn't that interesting, given the possible problems detailed in my first paragraph. But maybe that's just me.

Best regards,
Steve Berson

Bob L
06-23-2006, 10:23 PM
No SS does not handle an interleaved format beyond stereo.

I doubt I will be jumping on that concept any time soon... unless the industry throws all other support away in favor of that concept... not a good one in my opinion.

The hige file sizes would force limits on recording length in using 64 bit pointers... which would also slow things down tremendously... and what about head seek times going back and forth for each track.... can we say ridiculous. :)

Bob L

Bill Park
06-24-2006, 07:10 AM
The hige file sizes would force limits on recording length in using 64 bit pointers... which would also slow things down tremendously... and what about head seek times going back and forth for each track.... can we say ridiculous. :)

Bob L

Bob, You night consider talking to Matthias about the purpose of this method of recording. In terms of the head seek times, a big part of the idea seems to be to eliminate that occurence when recording, enabling you to record more files at once with a given hard drive. I don't know the result of then opening and splitting up the file on performance, but a simple defrag, if not the ideal situation (I don't defrag my audio drives during a project), should at least return the drive activity to what most people are used to experiencing. Particularly to those who insist on defargging.

Bill

Bob L
06-24-2006, 07:57 AM
I see the potential benefits during the recording proces of a straight uninterrupted performance of multiple tracks... but the file would then be a nightmare for editing and playback, unless completely separated into smaller independent files... in my opinion.

Currently, SS has no problems recording 48 tracks at once while also creating the peak data files on the fly... perhaps with 64 tracks or more being recorded at once, there may be some merit to the idea.

Bob L

Bill Park
06-26-2006, 06:31 AM
... but the file would then be a nightmare for editing and playback, unless completely separated into smaller independent files...
Bob L

Yeah, that is the idea exactly. Recording long format projects (2+hours)with less stress on the drive(s), and breaking them up in the audio editor into the component files.

Bill

Bob L
06-26-2006, 09:44 AM
I have not done the math, but my concern would be that a 2 hour file times 48 or more would be too long for even 64 bit pointers, especially at higher sample rates.

Bob L