Audio File Size Calculator

This utility calculates the size of audio files (both uncompressed, PCM/IEEE FP audio, such as .WAV/ .W64/ .RF64, .AIFF/.AIF and also lossy 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
Settings - Uncompressed (WAV, AIFF etc.)
Settings - Compressed (MP3, AAC etc.)
Uncompressed (WAV, AIFF etc.) 1411.2 kbps


Compressed (MP3, AAC etc.) 0 kbps



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 (please read our website rules before posting).


Leave a Reply to Colin Cancel reply

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

69 thoughts on “Audio File Size Calculator”

  1. This is exactly what I needed. I am looking at implementing an audio sampler of microcontroller board and needed to know the capacity I would need. This was the perfect tool for that. Thank you!

  2. Thanks for creating this, it’s a really useful resource that I come back to regularly. Is there any chance that you could add 256 kHz as a sample rate? This is quite common for ultrasonic instrumentation.


  3. A sound engineer has chosen to record the background audio for an upcoming movie in stereo. To produce a high quality non-compressed digital audio file, the sound engineer will use a bit depth of 16 and a sample rate of 88kHz. What would be the approximate resulting file size for a 1.5 minute 37 second audio track?

    can you help?

  4. Hello Colin, I am designing a studio and trying to calculate how much bandwidth / throughput my local server will need to be capable of, to be able to run large orchestral scoring session – of 400 tracks (96kHz/24Bit) across two Protools workstations, and a 4K video on a third – to arrive at which server solution would be correct.

  5. 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.

    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 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.

  6. 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 : declared for rhe usb2 protocol interface.
    In conclusion I will not buy an expensive USB3 or thunderbolt audiocard 😉

    1. 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 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?

      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).

  7. 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?

      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

        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.

  8. 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:

    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.

    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.

      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!

  9. Hi Colin, no matter how I try I don’t get the same result as the calculator. Do you mind showing me the maths working out please?

  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.

  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 ?

    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.

    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 🙂

      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.

      1. Hello collin how do i calculate this
        Video file has the following specifications
        true colour mp4 video compression ratio at 4:1 and size of 9000MB and duration of 3 minutes ,
        and audio compression ratio 2:1 at bit depth of 16bit, sampling at 96khz stereo

        a) the size of the audio component compressed in (MB) (2 Marks)
        b) the size of the video component compressed in (MB) (2 Marks)
        c) the size of the video uncompressed(MB) (1 Marks)
        d) the frame rate if the video has a resolution of 640×480 (5 Marks)

    1. Colin,

      I have a library of about 7000 CDS. Now that lossless streaming is a reality, I’d like to finally rip all of my CDs via my MacBook Pro to FLAC, store them on an external hard drive (and a backup) and upload them to the cloud for listening. I’m trying to determine what size hard drive to purchase. Is there a rough way to calculate this to determine how many TB I’m going to need?



      1. Hello Barry, FLAC file compression is lossless and programme-dependent so there’s no easy way to calculate exactly how much space you’ll save, especially with such a large library. For example, classical, jazz and acoustic music will, in general, compress down to much smaller files than loud genres such as heavy metal or EDM. Personally, I would go for a disk drive big enough to hold the ripped CDs uncompressed (in your case, at least a 4.5TB drive). That way, you can be sure you’ll have room to store everything and also likely have space to add to your collection in future.

        1. Dear Colin,

          Thanks very much for your swift response. Obviously, you can tell by my question that I’m a novice when it comes to these things, so I appreciate your understanding and helpful answer. So, just to confirm, you’re saying if I ripped all 7000 of my CDs (it is an eclectic mix of genres) uncompressed, it should generally be about 4.5 TB more or less? So, a 5tb hard drive should do the trick? Is there any benefit to keeping the files in an uncompressed format from a listening experience perspective or does lossless literally mean no quality will be losses if I convert it to FLAC? Is FLAC the lossless format you’d recommend? Lastly, do you have a recommendation for brand of hard drive and music software for this type of endeavor? I’ve asked you more questions than any character in Monty Python’s Holy Grail, and promise no more will be forthcoming. If any of my questions are outside your purview or comfort zone, that’s okay too. I just figure you seem an expert and very kind, so why not ask?

          Thanks again,


          1. Hello again Barry, No problem at all. Let me answer each of your questions in turn:

            Q1. “So, just to confirm, you’re saying if I ripped all 7000 of my CDs (it is an eclectic mix of genres) uncompressed, it should generally be about 4.5 TB more or less?”

            A1. That’s right. I used a (very) conservative estimate of 1 hour per CD. In my calculator (above, on this page), if you enter 7000 hours, and leave the other settings at their default (Sample rate: 44.1 KHz, Bit depth: 16 and Channels: 2), you’ll see that the uncompressed result is 4.44528 TB (we need the decimal output for this purpose). That’s likely the maximum amount of space you would need to store the uncompressed (wav or aiff) files.

            Q2. “So, a 5tb hard drive should do the trick?”
            A2. Yes.

            Q3. “Is there any benefit to keeping the files in an uncompressed format from a listening experience perspective or does lossless literally mean no quality will be losses if I convert it to FLAC?”

            A3. No. FLAC really is lossless, so there’s no quality loss at all – the original uncompressed files can even be restored by a conversion process if required; that’s not usually necessary though, since most computer audio software can read FLAC files directly and play them back in real time. They sound exactly the same as the originals. For more info, see

            Q4. “Is FLAC the lossless format you’d recommend?”
            A4. For your stated purpose, yes, absolutely.

            Q5. “Lastly, do you have a recommendation for brand of hard drive and music software for this type of endeavor?”
            A5. Re. Hard disk drives: I’m not going to recommend any particular make/model because they change often and I don’t keep up to date with them – you’ll find lots of reviews on the internet though. The one thing I would say is stick to a well-known and reputable brand. Re. Software: When I archived my own CD collection some years ago, I used the free, EAC software on Windows for ripping and it does a fabulous job. As far as I know this is the only software which allows a faithful reconstruction of the original CD (all gaps the same etc.). In reality, it’s probably overkill though, as I’ve never actually needed to do that. If you don’t care about reconstructing the original CD then most media players are able to rip tracks from CDs easily – several can convert straight to FLAC files, too. As far as playback is concerned, most media players can play back FLAC files directly. If you’re on Windows I’d recommend Foobar2000. On Linux, I prefer either Clementine (which also runs on Mac and Windows) or Rhythmbox. VLC player also does a good job and runs on Windows, Mac and Linux.

            I hope that helps.

          2. Dear Colin,

            Thank you so much. You have been incredibly helpful. I am so grateful for your knowledge and generosity. Refreshing in this day and age.

            Best wishes,