How much does a clip of digital audio "weigh" in filesize?

[rasputin1963]

I've been uploading seamless loops of digital audio to an online website, and I've observed something interesting: If you take three WAV audio clips, each one recorded in 44100/16-bit, each one lasting 4 measures long, recorded in at 90BPM.... you'll find that each turns out to have a different filesize in megabytes.

 

I dunno, I would've dumbly thought that each clip would weigh the same. One clip is of a drumkit groove, another is of a piano riff, the third one is of a Hammond B3 organ riff. All clips feature "all playing, all the time", with almost no silent moments.

 

Of the three, the organ playing weighs the most. All I can surmise is that, of the three clips, the organ is richest in frequencies, fat as it is with bass, midrange and treble frequencies.

 

So my question is: When you export a digital WAV, just what is its filesize ultimately measured by? Number of samples? Amplitude of waveform? Frequency variation in waveform?

 

A "busier" audio imprint yields more 1's and 0's for a computer system to store? This means that, let's say, a loud hard-rock clip of four bars, pegged to brickwall, will ultimately weigh more in filesize than the same four bars of quiet oboe playing?

 

 

Thanks, ras

 

 

 

[MikeRivers]

I've been uploading seamless loops of digital audio to an online website' date=' and I've observed something interesting: If you take three WAV audio clips, [b']each one recorded in 44100/16-bit, each one lasting 4 measures long, recorded in at 90BPM[/b].... you'll find that each turns out to have a different filesize in megabytes.

 

If they're radically different, then you're doing something different with them. There's no difference in file size between two recordings of exactly the same length because they will both have the same number of samples. One can be completely silent and the other can be filled with the wildest organ or drum parts you can play. But depending on how tight your cut it at the beginning and where you consider the end is because there will be some reverb trailing off at the end. And your timing may not be perfect.

 

44.1 kHz means there are 44,100 samples in every second of your recording. Assuming you aren't corrupting this by recording at some other sample rate and resolution and converting it to 44/16 (different conversion algorithms can give slightly different results since the waveform is actually reconstructed and resampled mathematically) or you aren't involving lossy data compression in the process (starting with samples that you got as MP3 files, for instance) the numbers should check out. But remember, it doesn't take but a few milliseconds difference in recording length to make an observable difference in the size of the file.

 

 

[dboomer]

Possibly you may be comparing mono to stereo tracks?

[Anderton]

Are they REX files? They do lossless data compression.

[rasputin1963]

Hmm, maybe it is the conversion causing the differences. I did indeed bounce all three clips down from 96kHz/32-Float to 44.1kHz/24-bit

[philboking]

If they are both WAV files (not MP3), both stereo or both mono, and last the same amount of time, they should be the same size. If the tempo was much lower on one, it would last longer, and be a bigger file size.

 

For WAVs it's simple math: 44100 samples/sec. For 16 bits, each sample is two bytes. For mono, 60 seconds would take 60 x44100 x 2 (about 5 MBytes). For stereo, double it.

 

For your scenario, 90 BPM is 60000/90 = 666.67 mS per beat. (60000 is the milliseconds in one minute).

4 Beats would last 2.667 sec.

For mono, that would be 117600 samples, or 235200 bytes.

Since a kilobyte is 1024 bytes, it would come out as 229.68 Kbytes or so.

 

If they are BWFs (Broadcast Wav Files, which still use the .WAV file extension) it is possible to embed metadata (copyright, author, relative start time; etc.) into the files. It's possible that this could account for differences too.

 

Since I'm already on the topic anyway, MP3 and WMF files are more complex; they basically code spectrum vs. time. For example, a 400 Hz beep lasting 1 second could be coded as 400, for a given number of frames (time divisions). So if the spectral content is complex, you get a larger file out of it than an equivalent loop with a simpler spectrum.

[MikeRivers]

Thanks for doing the math. What Ras hasn't told us yet is just how much difference there is in file size. To be exact, you really have to be exact. When counting bytes, a couple of milliseconds goes a long way. If one is 20% longer than the other, that deserves some looking-into.

[WRGKMC]

Differences can be accounted for when it comes to data compression based on protocol used. Silence between notes for example may produce a thousand measurements between a beat that are exactly the same. Instead of sending a 1000 bits of identical readings the data is instead coded using a few binary digits to make the packet easy to move from point a to point be (liken an interface to a hard drive. Once at their destination these packets are recognized as being compressed and are decoded back into larger strings of binary numbers.

 

This kind of compression is used in just about all kinds of digital data from fax, to video, communications you name it. You also have some kind of error correction with these kinds of files as well. If for some reason the packets don't make it from source to destination intact due to noise or jitter, they get retransmitted. The packets are counted at each end and are accounted for. (this is one reason for buffering)

 

How many digits the files wind up being is going to be different to some degree depending on just how complex the sound wave is. A song with no silence between notes and having many complex transients occurring will not be compressed nearly as much as a song that has simple waveforms and silence between the notes so its going to wind up being larger.

[blue2blue]

When talking about data compression of audio files, it's very important to make a clear distinction between lossless encoding (like FLAC and the similar but proprietary Apple Lossless Audio Codec, ALAC). and lossy encoding like MP3, Ogg Vorbis, AAC (M4A), WMA, etc. The latter permanently remove 'less necessary' data (typically, bandwidth-sucking very high frequencies) that follows the perceptually 'crucial' initial parts of the wave forms (the human auditory system puts a far greater emphasis on the early parts of sounds than later). The amount of data compression is generally defined by the bitrate it takes to send a given format, for example, lo-fi-ish 128 kbps, mid-fi 192 kbps, 'hi fi' (or at least generally imperceptible loss) 320 kbps. For comparison, while a 320 kbps stereo 44.1/16 bit mp3 or other lossy file may have generally imperceptible loss, a true, full-data-size stereo 44.1/16 file has a bitrate of 1411 kbps.

 

Now, there are two truly lossless audio file formats in use, FLAC and Apple's very similar (but slightly less efficient) ALAC -- and they behave somewhat more like the kind of lossless data compression WRGKMC describes above, although his description of the algorithm might lead folks to conflate graphics and document compression schemes like JPEG and ZIP with the substantially different algos used in FLAC and ALAC.

[nat whilk II]

I note that you say you have been uploading these WAV files. Are you looking at the filesize post-upload on some website?

 

If so, the guys at the receiving end of the website could be converting your files in some manner -

 

nat whilk ii

 

[MikeRivers]

The original poster didn't say anything about compressed formats, he said WAV files. But, Nat, you have a good point. If it's not a web site that he controls, there may be some format conversion going on after the upload.

 

But I want to see NUMBERS!!!!

[blue2blue]

But I want to see NUMBERS!!!!

 

What's in a word, eh?

 

[video=youtube;kZmb92MmRv8]

[rasputin1963]

Thanks for doing the math. What Ras hasn't told us yet is just how much difference there is in file size. To be exact' date=' you really have to be exact. When counting bytes, a couple of milliseconds goes a long way. If one is 20% longer than the other, that deserves some looking-into.[/quote']

 

This whole question arose because the loops website in question has a ceiling of 5Mb per uploaded loop. One loop I created was under 5Mb and thus was acceptable to upload; the B3 organ loop, also of four bars, 44.1/16 and same tempo... came to 5.66Mb. It was over the website's permitted ceiling, and thus was NOT accepted. All this isn't the end of the world, of course, but it is perplexing.

[WRGKMC]

^^^^ Put the file in and audio editor and do some trimming on the file. Trim the silence before the sound and after, then save it again and see how the file size changes. Try it again rolling off some treble, amplitude or some of the wave data then compare your finding. .

[blue2blue]

Except that it's a loop -- presumably already properly trimmed to the appropriate length for perfect looping.

 

Also, there's no reason why changing EQ or amplitude would affect a non-data-compressed file's size. A wav file header is 44 bytes long (not kb). The data space for a stereo 44.1/16 bit file should be able to be calculated by multiplying 1411 kilobytes (kb) x the number of seconds of audio or silence in the file. (Silence takes the same amount of space per second as audio in non-data-compressed files.)

 

 

http://www.topherlee.com/software/pc...wavformat.html

 

http://soundfile.sapp.org/doc/WaveFormat/

[MikeRivers]

 

One loop I created was under 5Mb and thus was acceptable to upload; the B3 organ loop, also of four bars, 44.1/16 and same tempo... came to 5.66Mb.

 

Hmmmm . . 0.66 MB represents about 6 seconds of mono or 3 seconds of stereo. 5 MB is a bit under a minute of mono, or 30 seconds of stereo. Isn't that kind of long for a loop? Still, at that length, a difference of a few seconds should be really easy to notice. Are you sure they're trimmed accurately, and to the same length?

 

An easy test is to load each file into its own track in a multitrack DAW program (everbody has one these days). Line up the start of the files and see how much difference there is between the ends. Then figure out why.

 

If you're into loops (and I'm not, myself) you know that the file needs to be edited very tightly at the beginning so the audio starts at the beginning of the file. The end can be tricky because you want some decay but you don't want it long enough to cause a noticeable drag in the time when looping the file around on itself. You have to cut off the tail at the point where the next beat would start.

 

You probably know all that, but take a close look at what you've done and you should figure out why the files are of different sizes.

[WRGKMC]

Since he is uploading the files to some server the mystery may be there.

 

Many streaming and storage sites use something called Wavpack. This is a Filer storage compression that saves space on servers except its non destructive and saves a waveform in a lossless compression schemes that can reduce a files storage size between 30%~70%.

 

https://en.wikipedia.org/wiki/WavPack

 

This is not the same compression used to chance sample sizes. Its more like a Win zip file (in fact win zip 11 incorporates this now) This storage compression provides full lossless restoration when you pull the file off the server for use. They also use this for storage on stand along and hand held recorders.

 

The files actually stored on that server can thereby read very different sizes when you go on line and see what you have stored there. I suspect this is the issue. The OP is expecting his on line file sizes he saved to be a true representation of what he has there when in reality they been have been compressed. Once downloaded that should be the same size as when he uploaded them.

 

This is why I asked he inspect the files with an audio editor and do some comparisons before uploading. He would know what he had based on length and content prior to uploading.

 

Then if the two identical sized filed wind up being different sizes after they are uploaded it comes down to storage compression. One file may compress to a different size then another.

[WRGKMC]

I was leading up to this since this topic deals with uploading files as you'll find in my next post. I suspect his upload site uses something like this or something similar. https://en.wikipedia.org/wiki/WavPack File size may be identical on his computer but once uploaded it can be vastly different. I haven't tested it but I suspect things like Amplitude and Frequency in a wave file will impact on line storage sizes on a server depending on the percentage it can be compacted to save drive space.

[MikeRivers]

Since he is uploading the files to some server the mystery may be there.

 

Many streaming and storage sites use something called Wavpack. This is a Filer storage compression that saves space on servers except its non destructive and saves a waveform in a lossless compression schemes that can reduce a files storage size between 30%~70%.

 

But if it's supposed to save storage space, it isn't going to do that by making the file bigger. What Ras needs to do is look at the file size on his own computer before he uploads it. If it's under 5 MB there, it shouldn't be bigger than 5 MB when it gets to the loop host server. If some such data compression is going on, two WAV files of the same size might end up being different sizes after processing, but if both are 5 MB or smaller to start with, the processed versions should be smaller than 5 MB.

 

Just to prove to myself that I wasn't making all this up, I made a file (about 30 seconds at 44.1 kHz 16-bit mono, which indeed came out to be about 2.5 MB) and duplicated it a few times. First I verified that all the copies were showed the same size in Windows. Then I normalized one, applied a goofy EQ curve to another, and compressed the third one to toothpaste, saved them all as 16-bit 44.1 kHz mono WAV files and they were still all the same size. Then I saved each one as an MP3 file and they were all different sizes.

 

So, still, I maintain that the problem, if it's not something goofy going on with the host system, is that the files aren't really the same length.

[WRGKMC]

^^ Agreed. I'd say since he based his file size on the tempo and measures being used. The organ clip must have sustained past the measures on either end and made the file longer or there's additional silence there that could be trimmed. From what it sounded to me he didn't know the file was longer then 5M until he tried to upload it. The server recognized it was too ling in size. I'm just not sure if the first file wasn't longer too and was compressible to 5M on the server.

 

The simple solution would be to use a different free storage site. Drop box which doesn't have file size restrictions just total space. I have dozens of full length songs in wav format uploaded to that site. Its very reliable too.