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.
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).
Enjoy!
Thanks! Super helpful
Lovely
How much space would be consumed for a typical 4:30 flac file?
Hi Sam, The amount of file compression applied when encoding FLAC files depends on the file compression level setting (level 5 is the default) together with the type of program material being encoded, so it’s impossible to accurately predict the resulting file size after compression. However, as a rule-of-thumb, you can expect a FLAC file to be between 50% to 70% of the original uncompressed file size. More info here: https://xiph.org/flac/
Muito obrigado! Me ajudou demais no meu trabalho.
Thanks Alex, I’m glad you found it useful.
Hi Colin,
Thanks for the resource! Would one normally expect a “simpler” audio file (one containing fewer instruments, or alternatively simply speech and not continuous music) to be smaller? That is, controlling for sample rate, bit depth, and channels, (time, volume, anything else), would a spoken word track be smaller than a song? Or a duet smaller than an orchestra?
Hi Darren, It depends – if the audio file is uncompressed (e.g. a .wav or .aif) then no, because it records the same number of samples irrespective of the type of content recorded (think of this a bit like an old style analog tape recorder – it will use the same length of “tape” for any given length of recording, regardless of content). However, the size of compressed audio files do very much depend on content. While lossless compression (e.g. FLAC, ALAC, WavPack etc.) can reduce audio file sizes to some extent (up to around 50%), the lossy (.mp3, .ogg etc.) formats are able to reduce audio file sizes to a much greater degree (though at the price of losing some of the original information).
Glad to hear my calculator is useful to you.
Good afternoon,
Why are 5.1 or 7.1 considered 6 or 8 channels?
I have read somewhere that the subwoofer channel has so little information that we could consider it as an almost empty channel. And multiply by 5.1 or 7.1.
Greetings and thank you
Hi Alberto, When producing surround sound audio to uncompressed audio (e.g., a multichannel .wav file), a 5.1 mix always requires 6 channels, a 6.1 mix requires 7 channels and so on (the “.1” is the LFE, or Low Frequency Enhancement channel, which is designed to contain low frequency content, but the producer can decide exactly what to put there, so it needs its’ own channel). That’s why, when calculating the size of an uncompressed, multichannel audio file it’s important to specify the sample rate, bit depth and number of channels that file contains (hence the labelling in the channel drop-down menu to which you refer) as these elements can dramatically affect the file-size.
In post production however, these uncompressed mixes are often converted into a delivery format such as DTS, AC-3 or similar, and these are compressed formats (similar to mp3’s) which employ matrix technology to encode the channels. The number of channels in this case is effectively irrelevant in calculating their file-size – what’s important is the bit-rate. You can just use the “compressed” result to predict their file size (you’ll notice that this compressed output file-size result is unaffected by any sample rate, bit depth, or channel information you may have entered).
Thanks for a very handy calculator! Much appreciated!
Many thanks Sam – you’re most welcome!
I have a 16GB sd card and would like to know how many hours of telephone quality audio, mono could be fitted into this. I read in an earlier post of yours, that when you made a blank recording lasting 74 minutes, it took up about 68mbs of memory. From that you concluded that there were 234 lots of 74 mins wav capacity on the sd card. Ie 290hours.
Is this correct? i am often asked how many minutes of recording someone could get into a 16GB card, and needed an easy explanation
Hello Robene, You can use my Audio Duration Calculator to calculate this, but of course you will need to be more specific (“telephone quality” doesn’t really mean anything in the digital world, older telephone systems were analog and newer digital systems are optimised for real-time transmission). For recording/storage, it’s still necessary to choose a file format. In order to maximise the use of space on your 16GB SD card, you first need to decide on a file format together with the minimum level of quality acceptable to you and use that (e.g. a compressed format such as Mp3 at 64mbps in mono perhaps, which would give you around 555 hours of speech on your 16GB SD card).
By the way, “From that you concluded that there were 234 lots of 74 mins wav capacity on the sd card. Ie 290hours.”: Nope, that wasn’t me.
Thanks for the calculator Colin! I must be missing something very basic but here’s a question:
How is it that 80 minutes of CD audio (44.1k/16 bit stereo) = approx 850 MB, can fit and play on a 700MB CD-R?
You’re very welcome, William! And that’s a good question which highlights the differences between when a CD-R is used for data storage as opposed to when it’s used as an audio CD. When you simply copy data files from your computer to a CD-R (including audio files such as .wav or .mp3 – e.g. for backup or storage), then it will be able to hold the maximum number of megabytes stated by the CD-R manufacturer on the disc label (usually either 650 or 700 MB). However, when you write to a CD-R as CD audio, the LPCM (Linear Pulse Code Modulation) data in the original file is used to write bitstream data to the CD-R instead. This bitstream data is read by your CD player when the disc is played back. Because of this, the limit a disc can contain when written as an audio CD is measured in time and not in bytes/megabytes etc. That’s why, when you buy a CD-R for writing CD audio, you should take note of the maximum playback time the CD can hold, rather than just its’ data capacity in terms of megabytes. Labelling varies between manufacturers but, for example, CDs made by TDK are labelled CD-R74 (for 74 minutes) and CD-R80 (for 80 minutes) and so on.
In other words, what’s important here is the time it takes to play back the audio, and not the size of the audio file(s) from which the audio CD is produced.
I understand this can be confusing, especially because when browsing the content of an audio CD from a computer, it can sometimes appear as if the audio CD contains several data files, one for each track. Even so, what it actually contains is raw bitstream data (plus one or more subtracks for indexing, etc.). This can happen because computers can read indexing information from the audio CD in order to identify its’ details (e.g. title, artist, track details, etc.) and represent those as if they were data files.
Hello, my question is the following: At the same sampling frequency, why is the size of an 8-bit WAV half that of a 16-bit WAV if 256 resolution positions are stored in 8 bits and in 16 bits do they keep 65536?
Hi Julio, It’s because, when doubling the file size, the resolution of binary integers does not double similarly, but instead increases exponentially (the result of 2 ^ n, where n is the bit depth, gives the actual resolution). That’s why, given the same sample rate and number of channels, the 65536 (2 ^ 16) positions in a 16-bit file can be stored in exactly double the space of 256 (2 ^ 8) positions in an 8-bit file.
You can find more information about this here.
You just stopped my brain being fried. Working out 3 gigs this weekend with 14 tracks of differing rates, time etc. I either launched my calculator oot the widow or used this and, woo hoo, in seconds I had all answers for all 3 gigs. Pure magic. Thanks
Hi Diane, Thanks – I’m very glad to hear it was helpful.
God Save the Colin Crawley… may thee be knighted by Her Majesty!
I was Audio Hijacking my playlist though the Airplay using 432 Hz Player App and realized that the file was in the machine SSD and not the RAID… got freaked out… googled audio file size calculator. I am tripping out over your laundry list of experience. Thanks for being yourself and creating this tool. Have a great week and stay close to the home fire. Love from the Post Oak Savanah!
Thanks Mick, Your comment made me smile – which is especially appreciated first thing on a Monday morning! 🙂
Reading yours on this Monday had vivid reciprocity on my face as well! Love ya!
😀
Very helpful, thanks! I’m getting SD card for my Zoom R8 and I was concerned if U1 writing speed would be sufficient. Turns out I could record 64 channels simultaneously at 24-bit / 48 kHz and U1 card would still handle it just fine.
I spent the time to figure out the formulas used by this site to find the file size of audio and the maximum length possible based on the disk size and bitrate, which I was able to make thanks to this site.
With that, I found out how to calculate the maximum bitrate of audio based on the audio length and the disk size. Here’s the formula if you want it for some reason:
((file size in megabytes / length in seconds) * 1000) * 8
If it weren’t for this site, I wouldn’t have been able to make it, since I couldn’t wrap my head around how to do it earlier.
If you’re wondering what the point of being able to calculate the max bitrate possible to use, it’s useful for compressing audio to a specific file size, usually so that you can get around the file size limit on a website. But for me, it’s useful because it makes compressing audio to streamable file sizes much easier.
Glad you found this site useful and that you found a solution. You are indeed correct, though your formula could be simplified for clarity. In fact, the simplest formulae for calculating either file size, duration or bit rate would be:
File Size (bits) = Duration (seconds) * Bit Rate (bits per second)
Duration (seconds) = File Size (bits) / Bit Rate (bits per second)
Bit Rate (bits per second) = File Size (bits) / Duration (seconds)
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!
Quite helpful! Thank you
This is what I was looking for. Thx.
Great tool! Thanks for creating it.
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.
Thanks
OK Sam, it’s done. 😉
Hi,
I have a question about the audio channels.
How can there possibly be 65535 channels in an audio file?
Thanks!
Hello Saturn, Because 65535 really is the maximum number of audio channels supported by the .wav file format. You can find more info here.
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?
Hello roury, Sure, just enter those details into the calculator above.
yes, sorry i thought i did something wrong but it’s all good now.. thank you very much
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.
Hi Aditya, It’s always good to know about the various ways in which people use my online tools. Good luck with your project!
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
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.
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 😉
Hi Andrea, That’s great – thanks for letting me know! 🙂
Thanks Colin this is really handy.
Hi Michael, You’re most welcome! Glad to hear it’s useful to you.
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?
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).
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?
Hi Emma,
It’s quite straightforward. The basic formula is: File Size (bits) = Duration (seconds) * Bit Rate (bits per second)
See also my comments above.
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
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.
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/
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.
What would cause a 5m17s 320kbps MP3 to be 28Mb? It seems insanely large compared to my other files as well as this calculator.
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.
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!
Is it just a stereo file? Maybe it has multiple channels encoded in there – ie surround sound.
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?
Cheers
Ken
What exactly are you trying to calculate (a specific example please) and how are you trying to work it out yourself?
**New** 32kHz Sample rate option added (as requested by Dan in the Audio Duration Calculator comments).
By the way, you may like to know I’ve just published a new MIDI Note to Audio Frequency Calculator. Do check it out.
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.
Good catch Alex, thanks. Fixed.
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 ?
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.
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 🙂
Hi Kim,
No, it’s MUCH more frequent than that – a sample taken only once every 5 milliseconds would result in an extremely inaccurate 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.
**Updated** Now calculates compressed (MP3 etc.) as well as uncompressed files!
This is brilliant, thanks friend!
Hi James, Thank you, and you’re most welcome!
Very useful, thanks so much
Great to hear – thanks Ved!
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
REQUIRED
Calculate
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)
This has truly made my work easier. Thank you very much!
Hi Miriam, I’m very glad to hear that. Thanks for dropping by.
Thanks for the calculator Colin. Really useful indeed.
Hi Paulo, Glad to hear you’re finding it useful. Thanks for the feedback.
Thanks for creating this calculator it was very useful!
Hi Anthony, You’re most welcome!
I had an ap on my iPhone – but I couldn’t find it. Googled you. Quick and easy. Thanks.
Thanks for your feedback, Pierre. Glad you found it useful.
Thanks! Very handy.
Very glad you find it useful, Matthew. Many thanks for letting me know.
Really handy, might I suggest adding in the ability to input a target file size and have the calculator determine the duration for you?
Thanks for your feedback, Spudzor! Good idea – I’ll see what I can do. Watch this space.
Well it took a while, but…Done! 🙂 See:
https://www.colincrawley.com/audio-duration-calculator/
This will come in really handy – thank you!
Really useful tool.
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?
Thanks!
Barry
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.
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,
Barry
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 https://xiph.org/flac/
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.
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,
Barry
Hi Barry, You’re more than welcome. Thank you for visiting my site and good luck with your CD archiving!