Calculating Mp3 File Size
by Jeffrey Sward
Some Characteristics and Ironies of Digital Audio Storage

Mp3 is a lossy format, meaning than when audio is converted to mp3 information lost. Stated alternatively, a cd ripped to mp3s and then subsequently burned back to cd will not be identical to the original cd. The cd-mp3-cd conversion will cause some level of audio degradation. A compressed format such as flac, however, is lossless, meaning no information is lost. Stated alternatively, a cd ripped to flac and then subsequently burned back to cd be identical to the original cd.

Files for portable audio devices generally need to be in mp3 format. This author rips his original cds to flac files for storage and then converts the flac files to mp3 for portable audio. It is also advantageous to reduce the dynamic range by a 2:1 ratio and normalize the volume to 100% when preparing mp3 files for a noisy environment, such as an automobile.

Ironically, even though mp3 is a lossy format, mp3 files are sampled a constant rate (per file). The constant sample rate is amenable to predictable file sizes, when knowing the duration of the audio and sample rate.

Fundamental Mp3 File Size Algorithms
sec = duration of audio (in seconds)
bit = bit rate (in kilobits per second) (sample rate)
file size in kb  =  (sec * bit) / 8 (Note kb is kilobytes, not kilobits, hence the 8).
file size in mb  =  (sec * bit) / (8 * 1024)  = (sec * bit ) / 8192
file size in gb  =  (sec * bit) / (8 * 1024 * 1024)  = (sec * bit ) / 8388608

One hour at 256 kbps = (3600 * 256) / 8192 = 112.5 mb
One hour at 256 kbps = (3600 * 256) / 8388608 = 0.109863281 gb

sec = (gb * 8388608) / bit
hours = (gb * 8388608) / (bit * 3600) = (gb * 2330.17) / bit

hours per gb at 256 kbps = (gb * 2330.17) / 256 = gb / 9.102222222
Fundamental Size Relationships
  • One hour at 256 kbps = 0.109863281 gb
  • One gb = 9.10222 hours at 256 kbps
  • 32 gb =291.27111 hours at 256 kbps
  • 240 hours at 256 kbps = 26.3671875 gb
Your Results Will Be Different and Substantially Less

The proud owner a brand new 32gb mp3 player might reasonably expect to be able hold 291 hours of music. In a pig's eye!

The above calculations are the theoretical maximums, not actual values. File systems never ever hold their actual capacity. All file systems store files in sectors. Each file is stored within its own sector set. Files do not share sectors. Assuming file segments are contiguous, the last sector for any particular file will always be only partially full.

Consider a file system with 4096 byte sectors. Suppose we are storing 100 files of difference sizes which average 10k bytes each . The amount of space used would then be 100 x 10000 / 4096 = 245 sectors = 1,003,520 bytes. Wrong answer! On average, we would expect the last segment of any file to be half full (some being nearly empty and some being nearly full). There will be 100 last sectors, one for each file. Therefore, since each file contains on average 2048 bytes of unused sector space, we need to add 100 x 2048 = 204800 bytes to the amount of storage needed. Then the total amount of space used for the 100 files which average 10k bytes each is 1,003,520 + 204,800 = 1,208,320 bytes. Phrased differently, in this example, it would take 1.2mb of file system space to store 1.0mb of data.

In addition to space lost to sector boundaries, all mp3 players take part of the storage space to run their own software.

This author acquired a fancy schmancy 32gb Creative Zen mp3 player. Per the theoretical maximums, this device should hold 291 hours of music at 256 kbps. In actuality, because of software space and lost sector space, a 32gb Creative Zen mp3 player barely holds 240 hours of music at 256 kbps.

Additional Complications in Calculating Exact True File and Capacity Sizes

Ever since the invention of computers by cave dwellers in the Jurassic era, data in computers has been addressed by and stored in units which are powers of two. Because computers are a binary electrical system (zero = off, one = on), two is the natural unit of measure. For example, storage tends to be in units of 2, 4, 8 , 16, 32, 64, etc. Unfortunately, the coincidental relationship:
210 = 1024
causes a great deal of confusion. Is a kilobyte 1000 bytes or 1024 bytes? The answer depends on context and convention. Historically a kilobyte meant 1024 bytes because the units of storage were always internally in powers of two. However, usage has developed were a kilobyte sometimes means 1000 bytes. The use of kilobyte to mean 1000 bytes is popular with disk drive manufacturers who realized that they can deliver smaller drives with the same designation. Many disk manufacturers now publish elaborate disclaimers which explain in great detail how sizes are calculated. The definition problem escalates as the numbers get larger, such as:
220 = 1,048,576
which creates a similar issue of the definition of a megabyte. Fortunately, at least 1 byte = 8 bits in normal usage.

When written to media, files generally have headers and trailers in addition to the actual data. For example, in most operating systems, a txt file will have a four byte header which is the byte count of the actual text which follows. A file named mh.txt containing the text "Mariel Hemingway" (without the quotes) will consist of a four byte header with a hexadecimal value of 0010, followed by the 16 bytes of the actual text. The total amount of disk used is therefore 20 bytes for mh.txt. Mp3 files generally have headers and trailers. Obtaining information about the headers and trailers of the internal structures of files, such as mp3, is difficult and obscure. It is helpful to at least consider consider that the headers and trailers will be present.

In addition, mp3 files generally contain metadata ahead of the actual sound. The metadata consists of character representations of the title, artist, genre, etc. The amount of space used by the metadata depends on many factors, the most important of which is the particular tag editor and/or utility which supplies the metadata.

When a file is written to a file system on disk, a corresponding entry is made in the directory index. The directory index entry requires space for a copy of the file name, plus pointers to the location of actual file.

Knowing the exact size of any particular file also depends on the reporting conventions used by the operating system. Assume we have written the above mh.txt file to a disk with a sector size of 1024 bytes. The file will occupy the full sector. When listing the length of the file, will the listing of the mh.txt example show 16 bytes, 20 bytes, or 1024 bytes? The answer depends on the operating system and file type. Unix and windows are notorious for counting the length of files differently. Often a file copied between unix and windows using ftp will show as a different length in the two locations, even though the file was copied exactly.

Finally, a particular disk or solid state storage device differentiates between between "actual" space and "usable" space. This is because the hardware itself uses part of the disk space and the file system (such as ntfs or fat32) uses part of the disk storage. A recent one terabyte disk drive had only 938gb of usable space.

Summarizing the above, calculating exact true mp3 file size requires knowing:

  • The number of bytes the actual sound uses
  • The convention for size naming (kilobyte, etc.) used by the manufacturers
  • The exact header and trailer sizes of the mp3 file format
  • The amount of space used for metadata

Summarizing the above, calculating exact true storage capacity requires knowing:

  • The sector size of the storage media
  • The storage space for software installed by the vendor.
  • The amount of space used for directories
  • The space reporting conventions of the operating system
  • The amount of space consumed by the file system
  • The usable vs. actual space of the media device
Welcome to the jungle.
Some Notes on Selection of Sample Rate contains an interesting discussion of a test of mp3 sample rates. The net results of these tests are that complex music sources, such as orchestral, played back with high fidelity equipment, generally require a sample rate of at least 256 kbps. Discernable losses of audio quality are palpable at samples rates less than 256 kbps. Hence, this author's example calculations above are based on 256 kbps.


All written content of this web site is solely the editorial opinion of Jeffrey Sward. All images, graphics, and written content of this web site, including the html files, are creative products covered by copyright law. All content copyright Jeffrey Sward 1975-2016. All rights reserved. No portion of this web site or its constituent elements may be reproduced in any form, by any means, without prior written permission. So there.