Audacity Forum

@Gale
Thanks for your efforts.
No problems, it is my pleasure. More to the point, it is good to keep my hand in now I am retired

However I can tell you that each dXX directory inside the eXX directory is written to until the d directory contains 256 .au files, then the next "d" directory in the sequence is populated with .au files.
This is NOT what I have seen. I have not counted these files as I did not think it was an issue though I think the number of .au files in each directory varies and last night I think I was seeing as low as 5-10 files (I think) but again, it was late and I was not looking too closely however you may find my latest screen shot interesting as this shows there are not always 256 files per directory. The screen shot is from an LP rip without a crash. The main picture shows the timing of each directory 'date modified' and the small pictures show the contents of each directory and date created. Look very carefully at these time and dates. Is there a clue here?

I have had a bad day ripping LP's and Audacity has not been well behaved, no crash but a right pain. After many 'fixes' to Audacity I now have your 256 files per directory (and one run that should have crashed with the Audacity settings but it did not). Don't you just love systems. At least I can prove what I have said re there not being 256 files per directory otherwise you may have started to dismiss my input.

I did not make an issue of it last night but the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning.

Each .au file is 1 MB in size by default.
This is not what I seeing, my files are 780MB and not, as you say, 1MB. |I don't know the relevance of this but I thought it was worth mentioning.

Thus assuming Audacity was actually writing data, then the greater the sample rate and bit depth, the sooner each directory will be filled and the next one populated.
The greater the sample rate the quicker the directories are written; this is agreed and explains the variation in time to crash being sample rate dependent. At the moment I do NOT agree that bit depth alters the rate of directory writes but please remember, my results of last night are based on a sample test of one. This is not statistically significant so I am looking at this now.

otwo_pipes wrote:I think it is very interesting Audacity is creating these directories but is not writing to them but is writing somewhere. The amount of available system RAM, during an audio capture, decreases to a certain point and then continually oscillates i.e. available memory rises, falls rises etc. until Audacity crashes.
1. Does the certain point before which Audacity uses RAM ever vary with its "Minimum Free Memory" setting? You seem to be saying not? If not, I think it may be an idea to try a 24x192 capture with minimum settings between 16 MB and 600 MB.
The 'certain point' varies dependant on the setting of the audio cache depth.
If the audio cache is set to 16MB then system RAM is used until only around 95-100MB of the system RAM is free then the oscillations start followed by a crash some time later. If the audio cache is set to 100MB then RAM is used until around 300MB of RAM is free then the oscillations start followed by a crash some time later.
The some time later is dependant on the time between each make directory. This time is dependant on the sample rate and may or may not be dependant on the number of bits in the sample. I know the time could be dependant on the number of bits in the sample but so far I have not seen this. The crash occurs after the make directory d06 and before make directory d07, about one third to half of the make directory time interval after directory d06 is made. As I said, this time is definitely dependant on the sample rate and may be dependant on the bit rate.

2. On what basis do you believe that when you reach this certain point, Audacity starts writing to disk, given it is not writing in the temp folder? The names of the .au files are random, but perhaps it would be an idea to search for .au files by date created, to find out where they are.
The reason, for my assumption, is very simple.... When capturing data at 'Rate' bytes per second the storage required is the 'Rate' multiplied by Time (in seconds) bytes. When this number exceeds the amount of RAM used, since the start of recording, Audacity must be writing somewhere and the VRAM, allocated to Audacity by Windows is continuously increasing from the start of capture. As I said, I now assume Audacity is writing to the Virtual Windows RAM. Windows could of course be allocating VRAM to Audacity and Audacity discarding the captured data. I have not looked for the .au files, I just assumed. Sorry for this assumption and I like your question.

3. Are you sure that after the certain point, Audacity is not writing to RAM as well as to disk, given Windows is continuing to allocate more and more virtual memory to Audacity? Might the available memory not be depleting further due to swapping to the page file?
I suspect, and always have, that Audacity is writing to both RAM and VRAM from the START of audio capture when audio cache is enabled. I know this is not how it is intended to operate but this seems the only explanation for what I am seeing. Remember, I do not have a development tool-set, only the Windows Task Manager tools. Let's assume Audacity settings are such they will cause a crash. There are numerous choices of settings but the results are always the same aka:-
The system RAM is continually decreasing to the oscillatory value, as explained before, AND the VRAM allocated to Audacity by Windows, or whatever, is continually increasing. These actions occur from the start of recording until the crash. Maybe the VRAM point is very significant. Let me ask the question: If Audacity/Windows has over 1GB (and maybe as much as 1.5GB) of system RAM available why should Windows/Audacity increment the VRAM allocated to Audacity from the start of the audio capture? This behaviour does not make any sense to me. Let me run it past you again:-
The system RAM available to Windows is continually decreasing from the start of recording until the critical available memory, which is dependant on the audio RAM cache depth:-
If the cache is 16MB the system RAM decreases to about 100MB
If the cache is 100MB the system RAM decreases to about 300MB
then the available system RAM oscillates around this figure whilst the VRAM allocated to Audacity has continued to increase from the start of the audio capture
I can only assume Audacity is writing to RAM and VRAM but cannot be certain because projects are never recoverable after a crash.

4. If you set the minimum to 600 MB are you getting RAM used until system RAM falls below 600 MB, then disk writes - i.e. does the procedure work as intended if the minimum is high enough?
I do not think so but this one is difficult to answer with the tools I have available. I think the RAM is used until somewhere in excess of 1GB is in use, but never as much as 1.4GB (I have 2GB RAM) and then the oscillation starts. The oscillations are from around 1GB to 1.3GB; it was late and I am hazy on this point. What I am certain of is the correlation between available RAM and the cache setting but it is only a correlation; the two are NEVER equal i.e. 16MB cache correlates to 100MB system RAM and 100MB cache correlates to 300MB system RAM. I think 600MB cache correlates to 1GB system RAM but I am not sure on that one. It was gone midnight when I finished capturing audio

otwo_pipes wrote:To progress I think we need to have independent confirmation of the above findings regarding the crash timing.
It's quite difficult to fix anything that the developers cannot replicate on their own machines. If the developers cannot reproduce it, we are looking at giving you a debug build of Audacity, then you installing Visual Studio and examining call stacks (even if you wanted to do that)
I have no problem trying to help, other than time. My priority is ripping my Vinyl collection to HD. I have around 800-1000 albums and it takes about one hour per album. This equates to........... a very long time. I am going to live in Thailand from October for 5-10 years. I will travel SE Asia on my Valkyrie motorbike using Thailand as a base... now I am digressing Re the de-bug build and VS; here I may be out of my depth and require hand holding. I am not a softie and have little experience of software de-bug as my background is hardware design. I finished my career consulting for the likes of Nokia, TI and Sony Ericsson. I have interfaced with, and assisted softies with hw/sw de-bug, a great deal but as to hands on........... anyhow, I am game if someone can assist when I have problems.

Also, it is quite difficult trying to de-bug at a distance. I need to be accurate and not cause further confusion and to this end this update has taken many hours to write. I was also ripping LP and trying to sort other Audacity problems but that is another story. I have to read the FAQ first Gale, from my point of view It may be more efficient to Skype me if you are interested, I am dennis2pipes. (The 2pipes comes from smoking a pipe and always carrying two hence....) If you see me on-line in Skype then you can call but please not this evening. I am too tired and testing some ideas with this Audacity problem.

@Gale: Thus assuming Audacity was actually writing data, then the greater the sample rate and bit depth, the sooner each directory will be filled and the next one populated.
@2pipes: At the moment I do NOT agree that bit depth alters the rate of directory writes but please remember, my results of last night are based on a sample test of one. This is not statistically significant so I am looking at this now.

You are absolutely correct as the memory requirement is dependant on sample rate and bit depth. What is interesting the crash ocours at 19:19 when captured at 24/192 and 38:38 when captured at 16/192. This implies Audacity is using two words for storage when the bit depth is 24.

@Gale: 2. On what basis do you believe that when you reach this certain point, Audacity starts writing to disk, given it is not writing in the temp folder? The names of the .au files are random, but perhaps it would be an idea to search for .au files by date created, to find out where they are.
@2pipes: The reason, for my assumption, is very simple.... When capturing data at 'Rate' bytes per second the storage required is the 'Rate' multiplied by Time (in seconds) bytes. When this number exceeds the amount of RAM used, since the start of recording, Audacity must be writing somewhere and the VRAM, allocated to Audacity by Windows is continuously increasing from the start of capture. As I said, I now assume Audacity is writing to the Virtual Windows RAM. Windows could of course be allocating VRAM to Audacity and Audacity discarding the captured data. I have not looked for the .au files, I just assumed. Sorry for this assumption and I like your question.

Section 2 was all based on a wrong initial calculation. One minute of capture at 24/96 uses 96k words per second or 96*4*60 bytes per minute i.e about 23MB per minute. Re-visiting and searching the hard drive has shown there are NO writes to VRAM during capture and prior to the crash i.e. there are no .au files on the hard drive after a crash. Sorry to have mis-lead.

@Gale: 3. Are you sure that after the certain point, Audacity is not writing to RAM as well as to disk, given Windows is continuing to allocate more and more virtual memory to Audacity? Might the available memory not be depleting further due to swapping to the page file?
@2pipes: I suspect, and always have, that Audacity is writing to both RAM and VRAM from the START of audio capture when audio cache is enabled.

The above has now been proven to be wrong. Apologies again.

@2pipes: The system RAM is continually decreasing to the oscillatory value, as explained before, AND the VRAM allocated to Audacity by Windows, or whatever, is continually increasing. These actions occur from the start of recording until the crash. Maybe the VRAM point is very significant. Let me ask the question: If Audacity/Windows has over 1GB (and maybe as much as 1.5GB) of system RAM available why should Windows/Audacity increment the VRAM allocated to Audacity from the start of the audio capture? This behaviour does not make any sense to me. Let me run it past you again:-
The system RAM available to Windows is continually decreasing from the start of recording until the critical available memory, which is dependant on the audio RAM cache depth:-
If the cache is 16MB the system RAM decreases to about 100MB
If the cache is 100MB the system RAM decreases to about 300MB
then the available system RAM oscillates around this figure whilst the VRAM allocated to Audacity has continued to increase from the start of the audio capture.

The above still stands. I have seen some variation but I do not think the variation is significant.

Given the previous erroneous assumptions I made I am now at a loss to explain the oscillatory nature and why the continually increasing VRAM from the start of audio capture when the cache is enabled? Not much is making sense at the moment. Maybe it it time for me reply to any posting regarding these points and then make various detailed measurements until I have some sound ideas.....

Apart from the one run at 16/192 testing has been at 24/192 in order to reduce the time to crash.
Of two crashes I have seen, files have been written in .d0; 5 on one crash and 14 on the second. All other crashes I have looked at have no files written to the dxx directories.
I have run a capture at 24/192 for 1.5 hours with audio cache off. I have a huge temp directory, 5.6GB & 7.5k files. The reason for such a large collection of data was to look at the VRAM which was 36MB at the end of the collection which is, give or take, the size at the start of the run.

Gale: I think the audio capture of 38mins 47secs requires about 890MB of RAM (96k samples x 4bytes x 38.75 minutes x 60 seconds) Please confirm my calculation. The reason I ask is the crashes seem to occur at the changeover from RAM to HD writes however this does not explain why there is not a crash when the cache is set to 600MB. Any thoughts?

otwo_pipes wrote: I am now at a loss to explain the oscillatory nature

Could this be to do with Windows memory management? (Windows moving RAM to page file when available memory gets too low).

otwo_pipes wrote:however this does not explain why there is not a crash when the cache is set to 600MB

Is that above the threshold for Windows swapping RAM to disk?

Hi Dennis

Thanks for your efforts.

So as I understand it, you don't crash with an Audacity setting of 600 MB, but you crash with a setting below that. System RAM appears to be no longer used at a point well above and roughly proportional to the Audacity setting. The critical point where RAM stops being used is accompanied by the start of reductions and replenishments of system RAM which are not observed prior to that point. On a couple of occasions only, .au files were written to the temp folder. Soon after this critical point is reached, Audacity crashes.

The onset of reductions and replenishments varies with the bit depth and sample rate of the recording and the Audacity setting, so this is not Windows swapping to the page file when system RAM falls below the Windows threshold point. Fair summary?

otwo_pipes wrote:the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning.

Even after you pressed the Stop button, there were no .au files in d01?

Also I note in your last image above of the folder structure, there was no d0c folder? And had it already populated d00 - d99?

otwo_pipes wrote:One minute of capture at 24/96 uses 96k words per second or 96*4*60 bytes per minute i.e about 23MB per minute.

I think the formula is: So as you can see that gets us to roughly 33.75 MB per minute assuming stereo.

I agree the block file size for 24-bit (irrespective of Audio Cache being on or not) is 780 kb. I am not sure why that is at the moment. The block file size for 32-bit and 16-bit is 1 MB.

otwo_pipes wrote:I think the audio capture of 38mins 47secs requires about 890MB of RAM (96k samples x 4bytes x 38.75 minutes x 60 seconds) Please confirm my calculation. The reason I ask is the crashes seem to occur at the changeover from RAM to HD writes however this does not explain why there is not a crash when the cache is set to 600MB.

38.75 minutes of 24-bit 96000 Hz stereo is about 1.3 GB of file usage. Isn't that about the amount of RAM you said you had to spare at the time you started to record?


Gale

otwo_pipes wrote:One minute of capture at 24/96 uses 96k words per second or 96*4*60 bytes per minute i.e about 23MB per minute.
Okay, thank you for the correction as I forgot the the 2 channels for stereo, and other points, when I wrote this but my spreadsheet was correct
betwixt us we may get there....
@Gale copied an equation from documentation:

I think the formula is:
Code: Select all
size in MB = sample rate in kHz * number of channels * (bits per sample /8) * time in seconds / 1024

here follows the short (honestly, this IS the short) answer to an important point. I will answer the other points later:-
I think we have a classic case of the numerical units provided in the equation above not being entirely correct. I know exactly what is meant but I still think the numerical units are not quite correct. We all know k * k = M (capitals as per Gales equation) however Gales equation uses MB on the left and kHz (meaning 1000 in frequency) AND 1024 (meaning k in software terms) on the right. The 1024 refers to 1k byte of RAM. This leads me to think we have a classic example whereby k * k does not equal M. In my mind, this concept is simple but has proven extremely difficult for me to explain in writing so please bear with me whilst I try to explain.
Can we assume, for the point I am trying to make here ,we have an 8 bit system i.e each sample is 8 bits (keep it simple, 8 bits = 1 byte).
Let me start by asking a hypothetical question:-
In a system with 1 MB of RAM and a sample rate of 1 kHz and only 1 channel (I did say lets keep it simple) how long can we write to RAM?
The answer to this question is hopefully, also simple:-
1 MB(yte) of RAM at a sample rate of 1 kHz and 1 byte per sample has to be 1e6/1e3 = 1e3 or 1k seconds: no problem; or........... is it a problem?
Let me ask another (simple) question, what is the magnitude of 1k (in this context)? Is it 1000 as in kHz or..........to continue..
re-arranging the equation quoted by Gale we have:-
time in seconds = (size in MB) / (sample rate in kHz * number of channels * {bits per sample /8} * 1024)
or simplifying as we have a sample width of 1 byte and only 1 channel:-
time in seconds = (size in MB) / (sample rate in kHz * 1024)
putting the same numbers from my hypothetical question above onto this equation we have:-
1e6(MB)/1e3(kHz)/1024 = 1,000,000 (from MB)/ 1,000 (from kHz) / 1024 = 0.9765625 k seconds
or should that be
1,048,576 (from MB) / 1000 (from kHz) / 1024 = 1.024 k seconds
or even
1,048,576 (from MB) / 1024 (from kHz) / 1024 = 1 k seconds
as I asked, what is the magnitude of 1k?
I think it is glaringly obvious that something is very wrong here. We cannot have one equation with three different answers depending on how you define M or K.
If you have any doubt to my reasoning or logic please look at the following URL:-
http://en.wikipedia.org/wiki/Megabyte
here, the table at the top right actually states 1k = 1000 in decimal and 1024 in binary and I quote, "The megabyte is a multiple of the unit byte for digital information storage or transmission with three different values depending on context." What, I hear you ask, three different values depending on context please, give me strength and one wonders why we have errors in system design.......
I know, I have been there before and even seen 32 bits systems not work because the LSB was defined as........ I will leave the reader to ponder on that one
so, let me ask a rhetorical question... when the audio cache is set to 16MB in Audacity, how big, in decimal, is 16MB?
I know how big 16MB is; you know how big 16MB is but seriously are all the Audacity functions, maybe written by different people, referring to the same size for 16MB and are you sure you are using 16MB in the same 'context' (re the URL) as Windows/Apple and Linux? Is that an interesting question or is that an interesting question? Answer YES because you cannot have MB = kHz (samples/second) * bytes * time / 1024
1MB of memory = 1024 bytes * 1024 bytes and not 1000 * 1024 bytes...............
boy, was that difficult to write....
I hope the readers understand the point I have laboured here.

@Steve: I owe you an answer but I am not sure I have the knowledge to answer your question re Windows Memory Management.
I now have another tool at my disposal, Process Manager from Microsoft, so I may be able to answer your question later.

Hi Dennis

I am not a mathematician, but the point of the /1024 is to convert kb into MB for ease of working with the resultant figure.

If you want another much more complex formula which still gives a very similar result, try http://tinyurl.com/cb7tc3k .

However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of recording (with audio cache disabled) in the Audacity _data folder. Hence 38.75 minutes requires some 1.3 GB of RAM or disk space.

If I understood you to say that you usually have 1.3 GB RAM to spare before starting recording, and given your first image shows 300 MB RAM free when you crashed, then presumably some 300 MB memory had been swapped to page file by the time of the crash.

Was my summary at the top of http://forum.audacityteam.org/viewtopic ... 05#p185105 correct? And, next question below that, you are sure the folder d01 had no .au files in it even after stopping recording?



Gale

@otwo_pipes,
The formula given by Gale was correct. The amount of storage required to hold one minute of recording can be correctly calculated as follows:

Sample rate x number of seconds x sample format x number of channels = total number of bits
Total number of bits / 8 = total number of bytes
Total number of bytes /1024 = total number of KBytes
Total number of KBytes / 1024 = total number of MBytes

So, if recording CD quality (Sample rate=44100, sample format = 16bit), the actual numbers for one minute become:
44100 x 60 x 16 x 2 / 8 / 1024 /1024 = 10.094MB (to 3 decimal places)

There's no confusion, no doubt, no need to muddy the waters with esoteric arguments about K not equalling K. All you do is write the formula in words and then substitute the correct numbers.

PGA wrote:

Sample rate x number of seconds x sample format x number of channels = total number of bits
Total number of bits / 8 = total number of bytes
Total number of bytes /1024 = total number of KBytes
Total number of KBytes / 1024 = total number of MBytes

So, if recording CD quality (Sample rate=44100, sample format = 16bit), the actual numbers for one minute become:
44100 x 60 x 16 x 2 / 8 / 1024 /1024 = 10.094MB (to 3 decimal places)

and all I can say is I whole heartedly agree. You are absolutely correct and please, I am not trying to muddy the waters with esoteric arguments because, I think we all know, memory leakage can and does cause random and difficult to track, system crashes.

Unfortunately the formula Gale wrote is not the same as the formula you have written, the formula on the first line of the URL http://tinyurl.com/cb7tc3k Gale provided or the point I made in my post. There is one very important and maybe significant difference between these formulas and I am the only one that seems to have spotted this error. PGA, your formula, my formula and the formula in the URL all have two 1024's in the divisor. The formula provided by Gale has only one 1024 in the divisor (actually Gale has one divisor of 1000 for the kHz and one divisor of 1024). PGA, I am very pleased you agree with my statement that to convert bytes to MB you require two 1024's in the divisor but Gales' equation only has one.

Gale & PGA: the point I have been trying to make is the error caused dividing by 1000*1024 or 1024*1024 is slight but maybe significant with large data files. If Gale's formula has been taken from Audacity code, used for memory calculations, then we could very easily have memory leakage causing a crash. As formulas go the error is slight and is not really important UNLESS, as I said, the formula is used for memory calculations when we have a small error which, with a long recording time and huge data files obtained from my sample rate of 24/96, maybe grow into a significant error and cause memory leakage. However, this will not explain why no-one else has repeatable crashes using Audacity with the Audio Cache enabled or why I have not succeeded in causing my XP system to crash.

Gale wrote:

However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of
recording (with audio cache disabled) in the Audacity _data folder.

this is NOT what I see. As I said in my last posting, I have started to use Microsoft's' Process Monitor to look at memory usage and I have no reason to doubt the results obtained from the use of this program. My results are (with audio cache disabled);-

For 1 minute of recording, averaged from 6 measurements, recording at 16/96 the memory used was 23.2 MB/minute
For 1 minute of recording, averaged from 6 measurements, recording at 32/96 the memory used was 45.8 MB/minute
and the real interesting one is of course 24/96 capture whereby we have
For 1 minute of recording, averaged from 6 measurements, recording at 24/96 the memory used was 45.8 MB/minute

My testing to obtain these results was identical and my interpretation of these measurements is Audacity is using 4 bytes per sample for both 24 and 32 bit recording.

I wonder if:-

Each .au file is 1 MB in size by default.
This is not what I seeing, my files are 780MB and not, as you say, 1MB. I don't know the relevance of this but I thought it was worth mentioning.

I agree the block file size for 24-bit (irrespective of Audio Cache being on or not) is 780 kb. I am not sure why that is at the moment. The block file size for 32-bit and 16-bit is 1 MB.

has anything to do with the file size for 24 and 32 bit recording being identical to all intents and purposes.

Gale wrote:

However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of recording (with audio cache disabled) in the Audacity _data folder. Hence 38.75 minutes requires some 1.3 GB of RAM or disk space.

It would seem from my measurements 24/96 recording uses aprox. 46MB/min and 38.75 minutes would require about 1.8GB of memory. Not really relevant to the current problem but included for completeness.

If I understood you to say that you usually have 1.3 GB RAM to spare before starting recording,

Yes, that is correct. I have just looked at my system: I have between 1.1 and 1.5 GB free before starting any programs other than task manager

and given your first image shows 300 MB RAM free when you crashed, then presumably some 300 MB memory had been swapped to page file by the time of the crash.

I do not understand how you have reached this conclusion. I am not used to working out memory usage so do not know how you have drawn this conclusion. Could you please show me your calculations or reasoning to help me. I am HW based and not SW. I can see 1GB of RAM has been used because I start with 1.3GB and have 300MB free when the system crashed but I do not see how you can say 300MB has been swapped to page file. Sorry.

Was my summary at the top of viewtopic.php?p=185105#p185105 correct?
So as I understand it, you don't crash with an Audacity setting of 600 MB, but you crash with a setting below that.

Correct: I crash with Audio Cache enabled and set to 100MB and do not crash with a 600MB setting.

System RAM appears to be no longer used at a point well above and roughly proportional to the Audacity setting.

Correct: With a cache set to 100MB system RAM appeared to stop being used somewhere between 200 and 300MB depending on the run, i.e. the point when system RAM is no longer used is not consistent.

The critical point where RAM stops being used is accompanied by the start of reductions and replenishments of system RAM which are not observed prior to that point.

Correct:

On a couple of occasions only, .au files were written to the temp folder. Soon after this critical point is reached, Audacity crashes.

Correct: As I said in a previous posting, "Audacity will crash sometime after creating directory d06 but before creating directory d07"

The onset of reductions and replenishments varies with the bit depth and sample rate of the recording and the Audacity setting,

We have to be careful here. I am using an external box for the ADC function and so I believe, though I could be mistaken on this one, the parameters that matter are only the Audacity settings as these settings will overrule any settings on my external box. I think this is correct. Please correct me if I am wrong. Although my external box will go to 24/192 I have failed to get the M-Audio S/PDIF input to lock at 192 samples. The box output 192 samples but my audio card locks to half that rate therefore my Ripping has been carried out at 24/96. For testing I run my external ADC at 24/96 and alter the Audacity settings in the edit preferences menu for sample rate and bit depth. When I vary the Audacity settings your statement above is correct.

so this is not Windows swapping to the page file when system RAM falls below the Windows threshold point. Fair summary?

I am not sure you can draw this conclusion because I have seen some crashes whereby the directories created prior to a crash contain .au data. Therefore, in my naievety I would assume Windows has started to use the page file.

otwo_pipes wrote:the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning.

Even after you pressed the Stop button, there were no .au files in d01?

Sorry but I cannot remember if I had used Pause or Stop. I will watch for this again and let you know my findings. If I was to take a bet I would hazard I used Stop and not Pause.

Also I note in your last image above of the folder structure, there was no d0c folder?

Correct:

And had it already populated d00 - d99?

No. Look again at the main Windows Explorer image and the sub directories of the e00 directory. The directories are d0a -d0e with d0c missing and d06 - d09 only. There are no directories d00 - d99.

I do not know if this is relevant or not but when Audacity crashes it leaves, quite obviously, many directories and sub directories in the project directory. After a crash I always restart my system so I have a reference point to continue from. Audacity does not always clean the project directories correctly when re-starting i.e I have seen 4 project directories, one in use and 3 from previous crashes, when I took the directory screen shots. When Audacity crashes and I re-start Audacity asks if I wish to recover the data. I always decline as the one time I asked Audacity to recover the data either Audacity or my system frooze. Sorry but I cannot remember which it was.

And, next question below that, you are sure the folder d01 had no .au files in it even after stopping recording?

Answered above: I cannot be sure if I had stopped or paused.

If there are any questions outstanding please remind me.

Note: To complicate matters even further:-
The last testing I performed on Friday evening did NOT produce a crash on my Win7 system no matter what sample rate, bit depth or time tests were performed. Remember, I said I had one run on Win7 that should have crashed but did not. I have made no system changes whatsoever. The only change to procedure I started to adopt was I have deleted the Audacity temp directory due to Audacity not cleaning directories correctly when re-starting after a crash. I have downloaded the Microsoft Process Manager but this is an application which is not installed. Obviously I cannot tell if Process Manager has made any changes to registry settings but it sure is not installed. To run I have to use Win Explorer and find the app Process Manager in the directory to which the download was un-zipped.

otwo_pipes wrote:The formula provided by Gale has only one 1024 in the divisor (actually Gale has one divisor of 1000 for the kHz and one divisor of 1024).

I did, indeed, fail to spot the missing 1024 in Gale's formula. I didn't see any divisor of 1000 (other than the implied one caused by using sample rate expressed in kHz).

Agreed and thanks