Audio File Size Calculator

This utility calculates the size of audio files (both uncompressed, PCM/IEEE FP audio, such as “.WAV”, “.W64” “.AIFF/.AIF” and also compressed files such as MP3, WMA, AAC and OGG Vorbis), according to the recording duration and file settings you choose:

**N.B.** If you’re looking for a calculator to do the opposite (i.e. calculate duration from available space), then go here.

Audio File Size Calculator by Colin Crawley
Duration
Settings - Uncompressed (WAV, AIFF etc.)
Settings - Compressed (MP3, AAC etc.)
Uncompressed (WAV, AIFF etc.) 1411.2 kbps

0

0
Compressed (MP3, AAC etc.) 0 kbps

0

0

Enter the duration of your file in hours, minutes, seconds and milliseconds. Calculating the size of uncompressed files also requires the Sample Rate, Bit Depth and Channel information (but not the Bit Rate, which is automatically calculated). In addition to the duration, calculating the size of compressed files such as MP3 etc., requires only the Bit Rate information (in this case the Sample Rate, Bit Depth and Channel information is ignored).  For compressed files encoded with CBR (Constant Bit Rate), the displayed file size should be as accurate as possible (notwithstanding variables such as header information etc- see below). For compressed files encoded with VBR (Variable Bit Rate), the displayed file size can be slightly less accurate because in this case the bit rate can vary depending on the programme material.

Note that the file size reported by your device may vary slightly from that shown due to file allocation methods, possible differences in the amount of header information and/or the fact that some operating systems calculate hard disk space differently from others (e.g., some calculate it in binary and call 1kB 1024 bytes whilst others – and most hard drive manufacturers – calculate it in decimal and call 1kB 1000 bytes) – this calculator handles both methods.

If you find this useful and/or have any comments or suggestions then do let me know via the comment section below.

Enjoy!

Leave a Reply to Colin Crawley Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

48 thoughts on “Audio File Size Calculator”

  1. Hi Colin,
    I’m trying to get my audio book files uploaded to Findaway Voices audio book sales. I’m an author and I have NO idea about bits, etc. The files are 129 bits. The company needs the files in 192000 bits. That sounds like there’s so much disparity. What do I do? Hope you can help. Thanks.
    KJ

    Reply

    1. Hello KJ,

      It sounds as though you have recorded your audio book as mp3 files, yes? In terms of mp3 file encoding, describing a file as 128 or 129 “bits” makes no sense. It’s important to realise that mp3 file codecs (CODEC is short for encode/decode) are usually expressed in kbps, which stands for kilobits PER SECOND, in other words, this is the amount of data which is streamed per-second when you play the file, which is why it’s called the bit rate – it DOES NOT refer to the total number of bits in the file itself; the file size is determined by the duration of the encoded audio multiplied by the bit rate. The basic formula is: File Size (bits) = Duration (seconds) * Bit Rate (bits per second).

      It also sounds as though you perhaps used a variable bit rate (VBR) because 129 kbps (the files can’t possibly be 129 bps – that would be a ridiculously low bit rate) is not quite standard for CBR (continuous bit rate) mp3 files – although 128 kbps IS a standard bit rate, so this could simply be a reporting error.

      I took a look at their technical requirements and your distributor seems to require either mp3 files at 192 kbps or FLAC files at a sample rate of 44.1 kHz (and, presumably, because they don’t make this clear, 16-bit).

      In any case, it sounds like you recorded your files at either 128 or 129 kbps instead of the required 192 kbps, so you’ll need to correct them before submission. Because mp3 is a lossy format, re-encoding to mp3 at 192 kbps will inevitably degrade quality (which may or may not be acceptable to you). However, the way I would deal with this (short of re-recording) would be to convert the files to WAV (at 44.1kHz/16-bit), and then to FLAC (which is compressed but non-lossy) and use that as the delivery format – that way you won’t lose any quality from your original files.

      Since you ask for my advice; I suggest that you always to record to WAV files in future (which are uncompressed and non-lossy) and NOT mp3 (which are both compressed AND lossy). Mp3 is fine as a delivery format but (for several reasons too involved to go into here) far from ideal as a recording format. Personally, I would always record spoken material (music is a little different) as a standard WAV file at either 44.1kHz/16-bit or 48kHz/16-bit. You can then convert to mp3 (or whatever other format may be required) for delivery, keeping the original WAV files intact in case you might need to convert them to a different format later without any loss of audio quality.

      I hope that helps.

      Reply

  2. Hi Colin , thanks a lot for the tool ,it calculated that an usb2.0 audio card can easily support 24 channels of uncompressed audio at 192 khz and 24 bit rate with a total bandwidth of 13.824 MB /sec against a theorical max bandwidth of 60MB/sec (0,48 Gigabit/sec as described here : https://dt7v1i9vyp3mf.cloudfront.net/styles/news_large/s3/imagelibrary/i/interfacing_protocols_02-lwwiIvWXsToMpZqkCM_9DYygku0_DfHl.jpg) declared for rhe usb2 protocol interface.
    In conclusion I will not buy an expensive USB3 or thunderbolt audiocard 😉

    Reply

    2. Colin, can I ask a question? On the internet I found someone who supplied some ‘silent’ audio files at different lengths. Using ffmpeg I created a 74minute ‘silent’ audio wav file (named 74Min.wav). It is available here http://gregaiken.com/misc/74Min.wav the filesize of this file is around 67.8 mega bytes. I have successfully ‘burned’ this wav file to a redbook audio cd and indeed it plays for 74 minutes (of course with no sound). But how do we explain why it is a far smaller file size than it should be?

      Reply

      1. Hi Greg,

        No problem. I just had a look and this is the data I see from your file after downloading:

        Duration: 1 hour, 14 minutes, 3 seconds, 984 milliseconds
        Codec: WAV
        Channels: 1 (Mono)
        Sample Rate: 8000 Hz
        Bit Depth: 16
        Bitrate: 128 kbps
        File size (decimal): 71.1 MB (71,103,822 bytes)

        I’m not clear as to why you think the file size is smaller than it should be; when I enter the above data into my calculator it returns a file size of 71.103744 MB (decimal) or 67.809814453125 MB (binary), which is as accurate as can be expected (see my comments above).

        Also, it sounds odd that you were able to burn this file to CD at all; in my experience, most CD burning software will throw an error message if the file you’re trying to burn is not encoded as 44.1 kHz/16 bit stereo. Then again, perhaps the software you used to burn the CD automatically converts any queued audio file to 44.1 kHz/16 bit stereo before burning? Did you try ripping the track from the CD back into a .wav file? If you were to do that, I strongly suspect you would then find the resulting file size to be just over 1Gb (decimal).

        Reply

  4. Hey, I’m wondering how you developed the algorithm to predict the compressed file size from the uncompressed file size and the other parameters, I’ve been researching for hours upon hours and I can’t find anything online to point me in the right direction to understand how these approximations have been made! I’m wondering if you have any resources you could point me to?

    Reply

      1. This is wonderful method. I want to trim a file having Duration: 1.22.17 bit rate : 47kbps size: 28.2 mb size : 29,597,696bytes, such that it becomes less than 16 mb file, How can I use your method. as a layperson I have this issue. thanks

        Reply

        1. Hello Krish,

          If you enter the figures you quote into the calculator above you’ll see that you would need to reduce the bit rate of your compressed file from 47 kbps down to 25 kbps in order to keep it under 16 MB in size.

          Two things to note though:

          1. Is this really an audio file? If so, 47 kbps is extremely low (even for a lossy compressed format) and would likely represent pretty poor audio quality. Reducing it further may even render it useless.

          2. If you really must lower the bit rate, then you should convert the file again (but with the new settings) from the original, uncompressed audio file. Converting an already lossy compressed file again will reduce its quality even further.

          Reply

  5. Thanks for this Colin. I’m trying to do a “sanity check” on some file conversions using `ffmpeg`. What would make it more useful for me is if it included specific audio formats, and their compression ratios. I realize the compression is not a constant, but it doesn’t vary wildly either. The values given on the following website are consistent with my limited experience on this subject: https://fmedia.firmdev.com/audio-formats/

    Reply

    1. Hello Seamus,

      Thanks for your message and I’m glad you find my calculator useful.

      Thank you also for your suggestion. However, I feel it’s beyond the scope of this calculator to include additional specific formats and their compression ratios because AFAIK, the compression ratio of most formats (both lossy, with the exception of those which have a CBR option, and lossless) is programme-dependent and doesn’t vary hugely anyway. In general, I would need to be convinced that adding any functionality would increase the calculator’s value for a majority of users.

      Reply

    1. Perhaps you’re looking at the “Uncompressed” (instead of the “Compressed”) output? When I enter 5min 17secs at 320kbps into my calculator I see a result of 12.68 MB (under the decimal “Compressed” result), which is correct.

      …unless I’ve misunderstood you (sorry if that’s the case). If you’re saying that you have an mp3 of 5min 17secs that is, in fact 28 MB in size, then I can only guess that it must be padded out with data extraneous to the audio (e.g. tons of extra metadata, or even just zeros!). Why that might be is anyone’s guess though.

      Reply

      1. Yes, the actual file is that large. I guess I will need to look into the tags but I didn’t see anything suspicious by glancing at the file. I even removed 5mb of artwork and it’s still that big!

        Reply

  10. I think the binary (2^10) to decimal (1000) converter is off. It just multiplies by 1.024, but that only works for KiB -> kB. For MiB -> MB it needs 1.024^2, for GiB -> GB 1.024^3, and so on, given that the binary prefix equivalent is 2^(10*n/3), where n is the power in 10^n.

    Reply

  11. im trying to find out how often my RME is recording a sample pr second, im using 192 khz in 24 bit, how do I do that?

    I saw somewhere its every 2 ms, but I don’t think that’s right ?

    Reply

    1. Hello Kim,

      Since your audio interface is set to record at a sample rate of 192kHz per second, then it is converting audio at a rate of 192000 samples per second.

      For specific information about your hardware, I suggest you contact RME directly.

      Reply

    2. hi

      yes that’s in a full second but digital sampling doesn’t record all the time, as analog does, I think I got it now – 1/192000 x 1000 = 0,0052083333333333

      so that means it take a sample every 5 ms, someone correct me if im wrong 🙂

      Reply

      1. Hi Kim,

        No, it’s MUCH more frequent than that – a sample taken only once every 5 milliseconds would result in a very inaccurate (and audibly chopped-up) digital representation of the audio!

        You have the correct calculation but you’re interpreting the result incorrectly (i.e. the result is in milliseconds, not in seconds). In fact, a simpler way to express this calculation would be 1/192 (because one second = one thousand milliseconds). Either way, the result is 0.005208333 milliseconds which is, of course, a tiny, tiny fraction of one millisecond.

        Reply