Bug Report

[Dave Labrecque]

Windows will pad files on disk... perhaps this is all that is happening... note that disk size and filesize are reported as two different values on every disk file in properties.

I have not changed the wav file creation routines since the beginning 25 years ago. So far... I can find nothing wrong in the code.

Bob L

Total layman talking here: my understanding is that the padding Windows does with actual file size vs. size on disk is due to filling up of the last allocation unit for each file, not adding to the file itself. John, you're looking at the files themselves, right? Or maybe I'm talking completely out of school with this stuff. If so, apologies.

IIUC, John's seeing a difference in file structure between SS32 output vs. SS64 output of identical audio data (and dBpoweramp complains at the latter sometimes, but not at the former ever (so far)). FWIW. Do I have that right, John?

[Dave Labrecque]

I thought I was sure, but because you questioned it, I checked your two files again. The file "test SS32 output.wav" is 16 bytes short, as I thought. But, the file "Dog Bark SS32 output.wav" is not short - so I was wrong about it. I even went back and downloaded it again. Dog Bark SS32 output.wav was recorded at 48/16. test SS32 output.wav was recorded at 44.1/24. So, there is that difference (and it may be important).

Well, that difference is not important, apparently, to dBpoweramp: neither of those cause dBpoweramp to complain. This is consistent with my prior observation that it appears that no SS32-output WAVs cause the issue in dBpoweramp, while some SS64-output WAVs do cause the issue.

Just to thwart Murphy, I went back and checked the SAW64 files too. Dog Bark SS64.wav is recorded at 48/16 and it's off by 16 bytes. test SS64 output.wav was recorded at 48/16 and it's off by 16 bytes.

And, your file VO Demo_Mix.wav is recorded at 44.1/16 and it's off by 16 bytes. I believe that was also a SS64 file.

FWIW, "VO Demo_Mix.wav" was created from SS64 by Michael McInnis. His dBpoweramp had no problem converting it to MP3. I don't know if the MP3 parameter settings matter at all in this, but we did not discuss those, so his likely differed from mine. HOWEVER, it's also worth nothing that when I jump over to my Administrator user account and do the conversion there, dBpoweramp does not complain! What kills me is that giving my regular user account Admin status has not cured dBpoweramp of the need to complain at this same conversion!

My file "Pony Tail Girl Third Mix_Normalized.wav" is 44.1/16 and it's off by 16 bytes. It was recorded by SS64 - although at a higher fidelity and mixed down to that.

So that makes test SS32 output.wav the outlier. Are you sure that was recorded in SS32?

Unless I screwed up, yes.

If so, would you mind recording a couple more in SS32 at 44.1/24, and 48/16 and sending them to me so we have a little larger data set at those sample rates and sizes for SS32? If it turns out that the results are consistent, we should probably test all combinations of sample rates and sizes for both SS32 and SS64 since those variables might be important.

I've output a variety of files, each with different parameters for the same output data, from both versions of SAWStudio. Eight files total. You can download them in a single ZIP file here. It's about 15 MB.

Note that, again, none of these files that I've deliberately created trigger the dBpoweramp warning. I'm starting to wonder if there's a plug-in that's causing the trouble for dBpoweramp. These were all created with a completely empty mixer: no FX, no anything.

[John Ludlow]

Windows will pad files on disk... perhaps this is all that is happening... note that disk size and filesize are reported as two different values on every disk file in properties.

I have not changed the wav file creation routines since the beginning 25 years ago. So far... I can find nothing wrong in the code.

Bob L

No, that isn't it. I haven't been using Windows disk size. Mostly, I've been using UltraEdit file size. But, to be sure, lets use the implied file length from the wave files. One of the parameters of a wave file is the chunksize, which is the length of the rest of the file after the chunkId and chunksize. Since those are each four bytes long, then the file size is chunksize + 8 bytes. In every test I have done, that agrees with the Windows file size listed in a files properties, as well as what is reported by UltraEdit.

If we agree on that definition, and presuming that the files contain only the wave chunk, and the fmt and data subchunks then, since the data subchunk is the last subchunk, and the data subchunksize is therefore the length of the file after the data subchunkId and subchunksize, then the file size should be the data subchunksize + all the bytes before the last byte in data subchunksize (which is always 44 bytes in a SS wave). And so: chunksize + 8 bytes should be the same as data subchunksize + 44 bytes.

I'll do that for several files and, with Dave's permission, send them to you for verification - if that's OK with you?

But, you can also demonstrate it for yourself. Create some wave files in SS64 and look at them in your hex editor. Chunksize is always bytes 4, 5, 6, and 7 (0-based...) in a wave file. And subchunksize is always bytes 40, 41, 42, and 43 (again zero-based) in a SS wave file. As you know, chunksize and subchunksize are both big endian so you have to mirror-image them to arrive at little endian, which the rest of the pc world uses. I can't do hex to decimal base conversions in my head. I've heard that some programmers who work in assembler a lot can (which seems like a super power to me..) so maybe you can too. Being merely human, I use Windows calculator in programmer mode. I'll reiterate here that working in hex is uncomfortable for me. So, there's still a chance that I've missed something. But, at this point, I can't imagine what it might be.

What do you think - does that sound like a plan?

[Dave Labrecque]

...with Dave's permission...

Good by me.

[John Ludlow]

I've output a variety of files, each with different parameters for the same output data, from both versions of SAWStudio. Eight files total. You can download them in a single ZIP file here. It's about 15 MB.

Note that, again, none of these files that I've deliberately created trigger the dBpoweramp warning. I'm starting to wonder if there's a plug-in that's causing the trouble for dBpoweramp. These were all created with a completely empty mixer: no FX, no anything.

I downloaded them, Dave. Thanks! I haven't looked at them yet, but I'll work them over. Is it OK with you if I forward some of the files you've sent me to Bob so that we're comparing apples to apples?

[Dave Labrecque]

I downloaded them, Dave. Thanks! I haven't looked at them yet, but I'll work them over. Is it OK with you if I forward some of the files you've sent me to Bob so that we're comparing apples to apples?

You bet. Share away.

[John Ludlow]

OK, Bob, I checked out the 8 files that Dave posted the link to here in this thread, which comprise all the permutations of 2 sample rates (44.1 and 48) two sample sizes (16 and 24) and SAW32 and SAW64. For each file, I checked out the file length as reported by UltraEdit (a text editor with a hex editor), Windows properties file size (not size on disk), SawStudio chunksize + 8, and SawStudio data subchunksize + 44. As you can see, a pattern develops. For these eight files, all the ones created in SAW32 have a chunksize +8, and a data subchunksize +44, that agree with the file length reported by UltraEdit and Windows properties. Whereas, all the ones created in SAW64 have a data subchunksize +44 that is exactly, in each case, 16 bytes shorter than what is reported by any of chunksize + 8, Windows properties, or UltraEdit.

Maybe you could download Dave's zip from the link two posts back rather than have me send you the files?

Door open close with squeak_44.1 16 stereo 32.wav
........UltraEdit:..............1,470,044
........Windows properties:.....1,470,044
........chunksize + 8:..........1,470,044
........data subchunksize + 44:.1,470,044


Door open close with squeak_44.1 16 stereo 64.wav
........UltraEdit:..............1,470,044
........Windows properties:.....1,470,044
........chunksize + 8:..........1,470,044
........data subchunksize + 44:.1,470,028


Door open close with squeak_44.1 24 stereo 32.wav
........UltraEdit:..............2,205,044
........Windows properties:.....2,205,044
........chunksize + 8:..........2,205,044
........data subchunksize + 44:.2,205,044


Door open close with squeak_44.1 24 stereo 64.wav
........UltraEdit:..............2,205,044
........Windows properties:.....2,205,044
........chunksize + 8:..........2,205,044
........data subchunksize + 44:.2,205,028


Door open close with squeak_48 16 stereo 32.wav
........UltraEdit:..............1,600,044
........Windows properties:.....1,600,044
........chunksize + 8:..........1,600,044
........data subchunksize + 44:.1,600,044


Door open close with squeak_48 16 stereo 64.wav
........UltraEdit:..............1,600,044
........Windows properties:.....1,600,044
........chunksize + 8:..........1,600,044
........data subchunksize + 44:.1,600,028


Door open close with squeak_48 24 stereo 32.wav
........UltraEdit:..............2,400,044
........Windows properties:.....2,400,044
........chunksize + 8:..........2,400,044
........data subchunksize + 44:.2,400,044


Door open close with squeak_48 24 stereo 64.wav
........UltraEdit:..............2,400,044
........chunksize + 8:..........2,400,044
........Windows properties:.....2,400,044
........data subchunksize + 44:.2,400,028



........UltraEdit:..............2,400,044
........chunksize + 8:..........2,400,044
........Windows properties:.....2,400,044
........data subchunksize + 44:.2,400,028

[Bob L]

Not sure about Dave's files... but I just ran another test here on a session. Take a 32 bit session in SAWStudio32 and build a mix. Open the exact same session in SAWStudio64... build a mix to another output file. Both output files are exactly the same length... no extra bytes between versions.

Bob L

[jmh]

John,

You might try sox. There is a utility called soxi which will dump the info regarding audio files there may be some command line switches that turn up the verbosity of the output - I have never used it this way - but it may analyze the files and report about the exact questions you are asking. In fact you can use it for virtually anything as far as audio conversion is concerned - including mp3 creation.

[Dave Labrecque]

Not sure if it matters, but rather than share a session, I simply shared an audio file between SS32 and SS64. Single file on track one in an empty session. In each program.