Re: File Size Limitation

[Kurt Albershardt]

Jonas Eckerman wrote:
>
> For some reason it seems very difficult for many programmers to simply let
> the recorder close the first file, open a new file (using the same base
> filename with a number added to the end), and keep recording. This would
> allow the recording to go for longer than either the file system or file
> format allows, meaning the total length of the recording would only be
> limited by the amount of available space on the disk.

Most DAW apps I'm familiar with do exactly this, usually in 2gb chunks
by default.

[Mike Rivers]

In article > writes:

> > Instead of
> > just saying "sorry, you can't do that", it goes through the motions,
> > writes a file name but no data
>
> This sort of behaviour must be *very* irritating. And common from what I've
> seen written about it by users of different hard disk recorders and DAW
> software.
>
> For some reason it seems very difficult for many programmers to simply let
> the recorder close the first file, open a new file (using the same base
> filename with a number added to the end), and keep recording.

This is the way the Mackie records live. When you're recording
continuosly for more than 15 minutes, it closes the file it's
currently writing and starts a new one every 15 minutes. Record for
one hour and you get four (or maybe 5 if you're a little slow on the
button) files per track. If you want one file per track (for instance,
for a clean import to a DAW), you do this by rendering.

With a maximum disk size of 32 GB, if you're recording 24 tracks
(24-bit, 48 kHz) continuously, there isn't enough disk space to render
tracks longer than about an hour and a quarter. But if you're only
recording 4 tracks, you might want to record 5 hours continuously and
render them. Can't do it.

What the programmers lack is the vision that (a) disk drives might get
bigger some day, and (b) it's track-minutes that count on a non-linear
recorder. So they planned for it to do what they thought people wanted
to do with it, and didn't allow for us weirdos who figure that we have
a lot of recording time if you don't need a lot of tracks.



--
I'm really Mike Rivers - )

[Glenn Booth]

Hi,

In message >, Jonas
Eckerman > writes

>For some reason it seems very difficult for many programmers to simply let
>the recorder close the first file, open a new file (using the same base
>filename with a number added to the end), and keep recording. This would
>allow the recording to go for longer than either the file system or file
>format allows, meaning the total length of the recording would only be
>limited by the amount of available space on the disk. Maybe that's the
>problem. The programmers don't like long recordings. :-/

This problem was solved a few years ago by vendors of video capture
cards, in exactly the way you describe. They just create a sequence of
files with a 0, 1, 2... suffix on the filenames, then recreate the whole
file within the application.

Early generations of such software suffered occasional glitches, such as
the odd lost frame, but that seems to have been sorted out by the use of
sensible caching methodologies. Matrox, Pinnacle and a few others have
all implemented this type of approach, so maybe it's a case of educating
the programmers. If they can do it with 30(ish) Megabytes per second of
4:2:2 video, there doesn't seem to be any reason why they couldn't do it
with audio at similar data rates.

--
Glenn Booth

[Carey Carlan]

(Mike Rivers) wrote in news:znr1057098135k@trad:

> This is the way the Mackie records live. When you're recording
> continuosly for more than 15 minutes, it closes the file it's
> currently writing and starts a new one every 15 minutes. Record for
> one hour and you get four (or maybe 5 if you're a little slow on the
> button) files per track. If you want one file per track (for instance,
> for a clean import to a DAW), you do this by rendering.

With the caveat that this does not apply to the SDR 24/96, which writes a
continuous track for the duration of the recording (at least up to the 4
hours I've done in one pass).

[Mike Rivers]

In article > writes:

> With the caveat that this does not apply to the SDR 24/96, which writes a
> continuous track for the duration of the recording (at least up to the 4
> hours I've done in one pass).

Why not hook it up to an FM tuner, put one track in Record, and let it
run all night? I'm curious as to what it does. I got the impression
from the discussion here that the 2GB maximum rendered file size on
the HDR was a result of adhering to Microsoft's specification for a
gen-u-wine WAV file. I'd be curious if the SDR can produce a file
larger than 2 GB if you give it the chance.


--
I'm really Mike Rivers - )

[Dubz]

This link should explain a bit about FAT16/FAT32:

http://support.microsoft.com/support/kb/articles/q154/9/97.asp

In the MS-IE6 browser, it appears in the address field as this:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q154/9/97.asp&NoWebContent=1

Check it out, alternately tap "FAT32 size" (without the inverted
commas!) into google and have a look at the links.
----------
My info is this:

DOS, Win3.X, Win95A uses FAT16. Volume size from floppy to 4GB -
maximum file size 2GB.

Win95B (OSR2, OSR2.1), Win95C (OSR 2.5), Win98 and Win98SE, ME and XP
uses FAT32. Volumes from 512MB to 2TB (Terrabytes) - maximum file size
4GB.

WinNT4.0, Win2000 and I think XP also (I'm not exactly sure about XP
here) uses NTFS (NewTechnologyFileSystem). No practical limit to
volume/file size. Minimum volume size is 10MB.

Depending on your Operating System, your motherboard, your BIOS, and
the size of your harddrive, you may or may not be able to access over
8.4GB using FAT32. Even though you can *allegedly* get up to 2TB, or
files of 4GB, this doesn't always work in practise. This is mainly due
to harware limitations. More info available from support/knowledge
bases at WDC.com (Western Digital), Maxtor.com (harddrives) and
Phoenix.com (for the BIOS, navigate to products/bios, Award, or AMI).

It goes without saying that FAT and systems are tricky bidnis.
Later,
-=Dubz=-