Long Recording

[Bruce Callaway]

have a conference coming up where I will be recording for around 2 hours. This will be for speech and I will only need to have 3 tracks recording for this time. I recall a discussion here some time ago about making long recordings. IIRC, there was something you could do it SAW to split the recorded file into sections as you record without stopping the record function. Is this correct or is my memory really fading?

[Bob L]

Nope... you would have to stop then rename the base filename in the record setup dialog... it will then automatically adjust the track filenames...

But... for 2 hours... you should be fine at 44.1k or 48k... no concerns... especialy as mono voice tracks.

Bob L

[Bruce Callaway]

Thanks Bob...I will be using 44.1Khz so all OK.

[Scott P]

Bob,

There are times when I need to keep the SAW transport recording through long periods, like and hour. It works, no problem. But I would like to be able to punch in and out of various tracks without stopping. This is for something like an opera where I need to be able to turn on/off a solo track that only needs to record 5 min's of an hour, where everything else has to stay hot.

Any way to do that? Future possibilities?

Thanks!
Scott

[Bob L]

At this time... no... once record devices are engaged and active they must stay active... I do have the idea of disabling certain open record meters on the list... not sure what that may look like... or when it may show up.

Bob L

[Warren]

Nope... you would have to stop then rename the base filename in the record setup dialog... it will then automatically adjust the track filenames...

Bob L

Would two instances of SAW with ASIO do this SAW 1 recording part 1 and ending a few seconds after SAW 2 starts then goes to finish?

If the CPU can handle it 3 tracks would not the ASIO driver?:confused:

I just went back and tested it on an old cheapo laptop and it worked fine on a standard driver.
Thats the great thing about SAW so many thing you can do with it that you never thought would work, I like it.

[sebastiandybing]

Bob, I think I have been recording mono tracks for 6 hours without
any problems, I also thinks I remember you changed the sample counter
to full word lenght (what that is I don´t know).

Is it correct :confused:

Sebastian

[Bob L]

I had increased the internal variable pointers to double the length of the original counters... and 6 hours is pushing your luck. :)

Bob L

[sebastiandybing]

Is it then correct that 8 hours mono track is the max limit at 44.1/24 bit ?

Sebastian

[Bob L]

I usually switch files at about the two hour mark... although that is not the limit.

The math is somewhere here in a message thread for the calculation. The actual file does not corrupt as it writes because it is a continuous write operation.... the problem comes in later in the MT when you try to access data past the internal DWORD pointer position which will wrap around back to the front after the max limit is reached.

There are utility programs that use QUADWORD math for the pointer access and can break up the file into smaller segments, which can then be placed together on the timeline...

You can have regions back to back for over 24 hours on the timeline... but it is the max size of one file that will reach the position pointer limit after so many hours... and its different for each file format... res... and rate.

Bob L

[sebastiandybing]

I was meaning in Saw, I know these long files probably wont oppen in
other programs.

Before you did the pointer change, I just mark 2 hours sections and mixdown
to new files.

I think I will make a test to see how long a file can be in mono 44.1/24 bit.

One could say why doing that, but some day a someone whant a 3 hours
show recorded in 192 khz/ 24 bit...and then its really matters.

Sebastian

[Cary B. Cornett]

I just ran a test where I recorded for just over 3 hours and 16 minutes at 44.1 24 bit mono. I have no idea how much longer it might have run if I hadn't stopped it.

[AudioAstronomer]

I just ran a test where I recorded for just over 3 hours and 16 minutes at 44.1 24 bit mono. I have no idea how much longer it might have run if I hadn't stopped it.

I'm pretty sure it will go as long as you let it..

The problem becomes, 'how much of that can you actually play back'.

[Iain Westland]

i was wondering what the max would be at 16 or more mono tracks. i'd like to start recording bands rehursles.

[UpTilDawn]

i was wondering what the max would be at 16 or more mono tracks. i'd like to start recording bands rehursles.

Simple thing to do would be to change the base file name, or start a new, duplicate session during breaks.

When I record concerts I begin by setting up my first session with all the necessary track names, plug-ins (if any), even track order, etc... I save those settings under the session name, then save-as new names however many sets I'll need before I've recorded any tracks.... All set for the night and all that's needed is to change sessions at break time. I can always use "blend session" to put them all in one big one later if needed.

Just a thought.

DanT

Unless you don't take breaks... Frankly, I've never heard or been in a band that could rehearse for more than two hours without wanting to take a break.... If you can get a whole band to do that my hat's off to ya. :)

[Iain Westland]

not my band. i have an agreement with musicians, when they can play it i will record it how they want. i have carte blanche:)

but its a service i think could go down well

[Bob L]

SS will record for over 24 hours straight... no problem.... but... the issue is that during playback of a long single file, the pointer position inside the file gets too large for the variable in SS that does the file seek.... this was kept to a 32 bit DWORD value with the focus being placed on performance rather than giant long file access.

SS is about regions... smaller clips into larger soundfiles... so you can place regions back to back for the entire 24 hour timeline as long as each region access is within the boundaries of the 32 bit DWORD point to seek and access the data within the soundfile.

The max accessable filelength depends on bit res, and rate and whether it is mono or stereo.

16 bit mono files can go the longest... 24 bit high rate files can go the shortest.

Bob L

[Cary B. Cornett]

I'm pretty sure it will go as long as you let it..

The problem becomes, 'how much of that can you actually play back'.

I should have been clearer in my description. When I went to check the long files for playback, I had full access all the way to the end of the recording with no problem. So, I know that as long as I stick to mono files (as I now always do with live recordings), at 24 bit 44.1k I am good out to at least 3 hours 16 minutes. I still have no idea how much further I could go before running into "pointer problems".

I think it will be a LONG time before I need to record any event that is longer than 3 hours :)

[Ian Alexander]

OK, let's try asking the question a different way: What is the maximum file size that your 32 bit DWORD pointer will access properly?

We can do the math and figure out how long that will be at various sample rates and bit depths.

Thanks.

[DominicPerry]

I'm guessing a 32bit pointer can point to a 32bit file - i.e. 4GB

2^32 = 4294967296 bits

Dominic

[Bob L]

Unfortunately, the file pointer seek function is designed to cut the pointer variable in half, to be used as a positive and negative offset into the file...

So... we only have 7FFFFFFF hex which is 2147483647 in decimal, which we can use.... unless DDWORD values are carried throughout the code.

So here is how it works:

A 16 bit mono 44100 file.
44100 x 2 bytes per sec (16 bits) = 88200 bytes/sec
88200 x 60 secs = 5292000 bytes/min
5292000 x 60 mins = 317520000 bytes/hour
317520000 x 6.5 hours = 2063880000 bytes which is 7B044F40 hex... just under the max offset usable for the file position seek.

A 24 bit mono 44100 file.
44100 x 3 bytes per sec (24 bits) = 132300 bytes/sec
132300 x 60 secs = 7938000 bytes/min
7938000 x 60 mins = 476280000 bytes/hour
476280000 x 4.5 hours = 2143260000 bytes which is 7FBF8D60 hex... just under the max offset usable for the file position seek.

Looking back at the code shows that I modified the file seek routine calls in my program to allow the full use of the DWORD FFFFFFFF value in version 3.8 by translating just before the call to a DDWORD value and setting the Windows function call parameters to be happy with that... so... the max values above are now actually doubled... so a 16 bit mono 44100 file should be good up to 13 hours... I forgot that I did that. :)

You can follow the same concept for other formats and rates...

Stereo files are double the size above, therefore the max length is half of the above.

Bob L

[Ian Alexander]

Very useful. Thanks Bob.

[Carlos Mills]

Hi All,

I used a spread sheet to calculate this. Here is how it goes:

MAXIMUM NUMBER OF HOURS

16 bits (mono):

44,1 kHz - 13:30 h
48 kHz - 12:20
88,2 kHz - 6:45
96 kHz - 6:10 h

24 bits (mono):

44,1 kHz - 9:00 h
48 kHz - 8:15 h
88,2 kHz - 4:30 h
96 kHz - 4:07 h

p.s. you can use 88,2 and 96 kHz numbers to calculate stereo 44,1 and 48 kHz. They will have the same maximum lengh.

[sebastiandybing]

Thanks Bob for make this clear,
It would be very useful to have this info in the help file
in the beginning.

Sebastian