Apparent 2 Gig Instrument Size Limit???

[WTrachtman]

I have hit what seems to be an internal limit of the Gigasampler editor when trying to create a single instrument file larger than 2 Gigabytes.
I am in the process of building a 16 layer piano gigainstrument, which will end up being about 5 Gigabytes when all the layers are merged.
I have kept long recorded decay times to avoid looping.

However, it seems that no matter how much free space I have on my harddisk, the gigasampler editor will not recognize any free space above a 2Gig size limit. The edit reports:
\"Temp Free 2047.7 MB \"
in the status bar regardless of the fact that I have much more space free on my temp drive.
If I ignore this and try to load in an additional layer of samples which would cross the 2Gig size barrier, the editor warns me that the size may exceed the space on the temp drive.
If I ignore this warning and try to save the file with the oversized extra layer,then I get a \"error creating chunk\" error message when the process approaches the 2 Gig point and the editor save process aborts.

I will be sending an e-mail to the folks at Nemesys regarding this, but was wondering if any other folks have hit this 2 gig instrument limit.
If so, have any of you found a way around it.

I\'m running on Win\'98, and the disk partition itself is at 6 Gigs.
There should be plenty of room as far as Windows is concerned.

Thanks in advance for any help.

Regards,

Warren Trachtman

[Hans Adamson]

Hi Warren,
I have had the same limit as you describe no matter the size of free space on the drive. The warning from the editor also shows up if you are working on a file that is in the 1.6GB range. As long as I haven\'t exceeded 2GB everything has been fine.

Hans

[Kenn159]

Hi All
I can\'t say that I have experianced that because I haven\'t done much sampling with giga sampler but I just wanted to mention the reported limit of the soon to be released giga studio is 4 gig\'s per sample , I think they mean for each indivigual sample .I would asume the new editor will also support that . Ken

[Kenn159]

Hi W Trachtman
I think you miss understood me . It was posted that giga studio will support 4 gig\'s per indivitual sample, not patch . So there would be no need to reduce the size of your piano to 4 gig\'s . thanks , Ken

[WTrachtman]

Thanks for confirming the problem Hans. I was able to make a 7 layer, 1.97 Gigabyte in-process giga-instrument file with no problems. I only ran into this issue trying to cross the 2 Gig barrier.

Thanks also, Kenn159, for the info on the gigastudio limit. I should be able to cut things \"down\" to fit a 4 Gig limit for the upcoming gigastudio, but it is still disappointing to learn of this limitation.

Regards,

Warren Trachtman

[abi]

If I\'m not mistaken, GigaStudio supports \'distributed wave\'. What this means is that individual wave samples does not need to be on the same directory / harddrive. I think this will fix the maximum file size: while gigasampler uses only one file, gigastudio can have multiple.

I too would really like to have full 8 up and 8 down layers with every key sampled. I think the quality of this is much more superb.

[Hans Adamson]

Hello,

I dug up this old topic, because I am interested in the maximum file size issue. Now, is it possible to create a 4Gb instrument for GigaStudio or not? If so how is it done? Any need for the \"distributed wave\" implementation? (I am not familiar with what it means).

Hans

[Blob]

ok..here goes...

The problem seems to be the --¬ button to load and save your gigs (gsedit then uses your temp dir) the workaround seems to be as simple as using ctr+s to save your work (i got up to 2.4 gig before i ran out of instruments...and if this works for you i expect to be paid in Dan Dean WW http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif

BTW it helps to move your temp dir to the root of which-ever drive you are using..

The other option seems to be 2*2gigs edit and bugger about&then merge them into one

Hope this works for you..

ps. Anybody wanna buy a HUGE GM library (Dan Dean/Xsample..etc http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif


Just kidding

[Blob]

My temp dir read D:/Temp 9027 free

Could have something to do with it?

[Hans Adamson]

Ok, Blob,

Lets say, hypothetically, that I would want to create a sample library that was 4Gb large. I distribute it commercially in MultiDisk format. Would any GigaStudio user be able to play it? Maybe even GigaSampler users? (if the file size limitation only was related to Editor 1.0)

No imminent releases in the works, just speculating...

Hans

[This message has been edited by Hans Adamson (edited 05-26-2001).]

[Blob]

Of course they would http://www.northernsounds.com/ubb/NonCGI/images/icons/smile.gif

And why multi disk? can it not be released on DVD? (6.4 GB http://www.northernsounds.com/ubb/NonCGI/images/icons/smile.gif
Personally, i think the floodgates are open (kinda like the \'60\'s...summer of love/freedom for sample users..lets burn our Akai\'s..er..no,thats earlier,suffrajet stuff...\"any woman that want\'s to chain herself to MY railings and suffer a JET movement is ok by me\"..Lord Flash..anyway.) for Huge sample disks...i\'d buy it (as long as it wasn\'t a piano,allready got one collecting dust http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif

Maybe you could sample a nylon strung guitar propperly? (individual strings ala Larry Seyer,Ponticello/Tamburo..for that Malcom Arnold moment/different attacks with the thumb/the gentle sob of an artist playing Cavatina for the millionth time)

Anyway,mustn\'t ramble..Did it work?

[cc]

There is also a problem with Win98. Fat32 limits the size of an individual file to 4GB.

For some reason this seems to manifest as a 2GB limit in some systems, according to some sources. This is especially a problem for people doing video capturing - most software gets around this by using multiple files.

[killerbobjr]

Here\'s the problem (from Microsoft):

SetFilePointer
The SetFilePointer function moves the file pointer of an open file.

This function stores the file pointer in two DWORD values. To more easily work with file pointers that are larger than a single DWORD value, use the SetFilePointerEx function.

DWORD SetFilePointer(
HANDLE hFile, // handle to file
LONG lDistanceToMove, // bytes to move pointer
PLONG lpDistanceToMoveHigh, // bytes to move pointer
DWORD dwMoveMethod // starting point
);

Parameters

lDistanceToMove
Low-order 32 bits of a signed value that specifies the number of bytes to move the file pointer. If lpDistanceToMoveHigh is not NULL, lpDistanceToMoveHigh and lDistanceToMove form a single 64-bit signed value that specifies the distance to move. If lpDistanceToMoveHigh is NULL, lDistanceToMove is a 32-bit signed value. A positive value for lDistanceToMove moves the file pointer forward in the file, and a negative value moves the file pointer backward.

lpDistanceToMoveHigh
Pointer to the high-order 32 bits of the signed 64-bit distance to move. If you do not need the high-order 32 bits, this pointer may be NULL. When non-NULL, this parameter also receives the high-order DWORD of the new value of the file pointer. For more information, see the Remarks section later in this topic.

dwMoveMethod
Starting point for the file pointer move. This parameter can be one of the following values. Value Meaning:
FILE_BEGIN - The starting point is zero or the beginning of the file.
FILE_CURRENT - The starting point is the current value of the file pointer.
FILE_END - The starting point is the current end-of-file position.

*************************************************
-> Windows 95/98: If the pointer lpDistanceToMoveHigh is not NULL, then it must point to either 0, INVALID_SET_FILE_POINTER, or the sign extension of the value of lDistanceToMove. Any other value will be rejected.
*************************************************


Since lDistanceToMove is a signed long, that means a pointer is limited to 2^31 bits or 2147483648 bytes. But Microsoft is ambigous about the \"sign extension\" value in lpDistanceToMoveHigh, which may mean that a full 32 bit value can be used in lpDistanceToMove for 4294967296 bytes. Can\'t one just move a file pointer the maximum amount, then move it again from the current position? Not under Win95/98/Me. I would bet Microsoft stores the current file pointer value as a DWORD which means a 4G bytes maxmium distance from beginning to end.


Why not use SetFilePointerEx? From Microsoft:

Requirements
Windows NT/2000: Requires Windows 2000.
Windows 95/98: Unsupported.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

[Chadwick]

Damn...knew I should have taken that optional rocket science course in year 1....

[Blob]

Shurley some bright soul could \'hack\' the registry ?

[Hans Adamson]

Killerbobjr,

Is there a way to simplify your reply above, so that guys like me, with less developed computer chops, can get it?

Hans

[killerbobjr]

Simply put, Microsoft only uses four bytes to store a file position pointer. Each byte holds 8 bits for a total of 32 bits. In binary notation, 32 bits can convert to 4294967296 in decimal notation. Since one bit is used for either a positive or negative sign, that leaves 31 bits, or half of the 4294967296 = 2147483648. So this file position pointer can indicate a position from 1 (the beginning of a file) to 2147483648 (the maximum distance from 1). That is where your 2G byte size limit comes from.

And since the four bytes are hard coded in the Windows kernel, there is no item in the registry one can \"hack\" to change this.

We\'re stuck with this limit until Nemesys comes out with a Win2K/XP version.

[Hans Adamson]

Ok,

I get it. Thanks for the clarification.

Hans