An Overview of Apple Lossless Compression Results

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInEmail this to someone

I recently pointed out that the Apple Lossless codec has gone open source, meaning that this lossless codec can now be freely used in both hardware and software. The Apple Lossless codec (also known as ALAC) is similar to FLAC, and offers the same advantages. When you compress files in a lossless format, you lose absolutely none of the original data. Just as when you compress a text file using zip compression, decompressing returns all the original letters and characters, lossless music compression provides the full fidelity of the original audio you compressed.

It’s interesting to look at the sizes of files compressed in Apple Lossless format. (These file sizes are similar for other lossless formats, such as FLAC, SHN and APE.) I took a handful of CDs, and ripped some tracks to show how the amount of compression can vary.

When comparing file sizes, the easiest way is to look at the bit rate that displays in iTunes. (Comparing file size is more difficult, as the different files used would have to be the same length for this to be valid.) This is an average bit rate, but it gives an idea as to the amount of compression that was achieved. Different types of music, notably with different instruments, result in compression rates that vary widely. Compare the bit rates below to the bit rate of uncompressed music on a CD, which is 1411 kbps.

Here are some examples:

  • A solo harpsichord work by Johann Sebastian Bach: 902 kbps
  • A solo piano work by Johann Sebastian Bach: 554 kbps
  • A movement of a string quartet by Ludwig van Beethoven: 565 kbps
  • A choral work by Johann Sebastian Bach: 690 kbps
  • A piece for jazz piano trio by the Brad Mehldau Trio: 687 kbps
  • A live recording of a song by the Grateful Dead: 796 kbps
  • An excerpt from Steve Reich’s Music for 18 Musicians: 597 kbps
  • A movement of a symphony by Franz Schubert: 645 kbps
  • A song for male voice and piano by Robert Schumann: 446 kbps

Again, these figures are in no way absolute, and for each piece of music, the resulting level of compression could be different if the tempo, volume or instrumentation varied. But what they do show is that some types of music – notably solo harpsichord, which has a high level of harmonics at high frequencies – compress less well than, say, solo piano or voice and piano. The range of compression for these examples is from 36% to 68%, with the majority of the examples clustering around the 50% level.

Note that I haven’t tested much rock music, and especially not much recently recorded rock or popular music. With many recent recordings having high volume and using compression (not the type that reduces data size, but the kind that reduces the dynamic range of music), file sizes can be much larger. If you listen to recent recordings of such music, you’ve probably noticed that they are often very loud, compared with, say, recordings from a couple of decades ago, and these will result in higher overall bit rates when using lossless compression.




43 replies
  1. Galley says:

    If you compare the bitrates of CDs released in the ’80s and ’90s with the brickwalled discs we have today, you’ll find the average bitrate has increased from 850 – 900kbps to nearly 1100kpbs.

    Reply
    • kirk says:

      Yes, that’s the evil compression that I mention near the end of the article. When you look at a waveform of some of these discs as well, nearly every second peaks.

      Reply
        • kirk says:

          No, it’s nothing to do with fidelity. It’s all about making the music louder, and presenting a harsher sound that works better on the radio.

          Reply
          • Sam B says:

            When I worked in radio we had a dedicated hardware compressor as the final element in the signal chain before going to the transmitter. Our broadcast license specified what our max output could be over the airwaves, but the FCC technically allowed for a 5% margin over the limit, to account for sudden peaks, etc. Which in practice meant that every station I ever encountered CRANKED their compressor to run constantly at 105%. You would never see the needle dip. At this level of compression it’s basically just a hard limiter with almost zero dynamic level. After years of doing this, our ears grow accustomed to ultra-compressed audio, and it makes sense that recording studios are putting the finished product on CDs that is compressed to match what people hear on the radio and TV. Personally, I think it’s a shame, because we lose the subtlety of dynamic range, but it’s a dog-eat-dog world on the airwaves, and if you’re not maxing out your allotted wattage, somebody else is going to overpower your signal on the outer edges.

            Reply
    • Hamranhansenhansen says:

      You are confusing dynamics compression and data compression.

      The “brickwall” compression is *dynamics* compression. That is the compression of the dynamic range of the music itself. Soft sounds are made louder, or loud sounds are made softer, or both at the same time. That is applied to the audio material itself in the studio. It has nothing to do with the bitrate. Dynamics compression goes back to before bits were even invented.

      Data compression is not related to audio, it is related to digital files. Data compression is applied to the audio file, not to the audio. It compresses the size of the data, not any property of the audio program itself.

      Bitrate is not related to audio, that is related to digital networks. It’s the rate at which the bits travel over the network.

      The reason the bitrate matters so much to audio video is you want to listen or watch in real time. You want to play the first second of the media during the first second of listening, and the second second of media during the second second of listening, and so on. So if you want to stream a 1411 kbit/s audio file, you need a network with 1411 kbit/s bandwidth or greater, or the player will choke, it will have to stop and wait for more content before continuing to play the program. Because 1411 kbit/s that is too high for most networks, we make the audio file smaller using *data* compression before we stream it.

      The problem is, if we apply (lossless) data compression to a 1411 kbit/s audio file, we can only typically make them about half that size, which is still a very, very large stream. And as mentioned in this article, depending on the complexity of the music, data compression will give you different bitrates for every single song you apply data compression to, which is not ideal for say, a streaming radio station that has a 256 kbit/s stream that has to carry any arbitrary audio. The priority in lossless is to maintain the original audio data and audio quality precisely as it was on the CD. Bitrate is secondary.

      That is why a new kind of data compression was created, called “lossy,” where you throw away data to make an even smaller file than you could achieve just by compressing the bitstream. With “lossy,” we use perceptual encoding to create a file at an arbitrary bitrate such as 256 kbit/s (like iTunes Plus) and the encoder performs a bunch of very sophisticated tricks to create a brand new 256 kbit/s file that tricks the listener as much as possible into thinking they are listening to the original 1411 kbit/s CD audio file. The priority with lossy is to fit the audio program into the tiny arbitrary bitrate. Audio quality is secondary.

      Yes, you are right, there is a kind of arms race where music keeps getting louder. The fix for this is unlikely to happen before we move to consumer HD audio (the original audio from the studio, which is much higher quality than CD) which requires 24-bit playback hardware which typically has its own dynamics compressor built-in. So the music can ship with a wide dynamic range, and the playback platform can adjust the dynamics based on how loud the user is playing the audio, whether they are using speakers or headphones, and the dynamic range of other audio material. Or the user can turn it off and hear the full dynamic range. Apple’s SoundCheck is a step in this direction. Also, the fact that all Macs for some years now have had 24-bit audio hardware built-in is a step in that direction. Apple Lossless or FLAC can also hold a 24-bit audio bitstream, which MP3 and AAC and CD cannot (they are 16-bit.)

      You should take some comfort from the fact that at this point, music producers are typically just as unhappy with the “brickwall” as you are. So it is something we’re all trying to fix as we move from 16-bit to 24-bit consumer audio.

      Reply
      • kirk says:

        “Bitrate is not related to audio, that is related to digital networks. It’s the rate at which the bits travel over the network.”

        Bit rate is also a factor in file size: the number of kbps determines the file size. A 256 kbps file is exactly twice the size as a 128 kbps file of the same duration (assuming they are not using VBR).

        Reply
      • Joe says:

        Though you don’t need to move from 16- to 24-bit to avoid “brickwalling”… It’s not like 16-bit was ever a barrier to high-fidelity music. 16-bit audio provides more dynamic range than we can possibly hear from 99.999%* of listening environments. 24-bit audio is obviously useful in the studio, where production and mastering require the original audio data to be tweaked without any dynamic range loss… But I can’t see how traditional 16-bit audio is in any way related to why pop music is “brickwalled”.

        *Totally made-up stat but pretty much fact.

        Reply
        • kirk says:

          I agree. That process has nothing to do with the recording of music in 16- or 24-bit. In fact, most recordings are made in 24-bit or even higher, so the resulting releases on CD or in digital format are generally downsampled; and that downsampling has nothing to do with audio compression either. It’s simply something that’s added to – or imposed on – the music during the mixing process.

          Reply
  2. Joe says:

    I do a lot of vinyl ripping of my old dance records and find that the bit rate ranges from about 800 up to 1100 kbps. I wonder if the compression ability is limited by the random vinyl pops/cracks and low-level rumble noise (although I use filters to remove as much as possible).

    Reply
    • kirk says:

      That’s probably a fair assumption. The best way to find out would be to get a CD of some of the same music that hasn’t been remastered. If you can be sure that the volume hasn’t been changed, then there would be a difference. It’d have to be an old CD, though, as there’s a good chance that reissues have volume changes.

      Reply
      • Joe says:

        It’d be interesting to find out why dynamically compressed music won’t compress in file size as much. I would’ve assumed that it would compress more because a lot of the detail has been completely washed out of the recording.

        Reply
        • kirk says:

          I think it’s simply because the overall volume is higher. When dynamic compression is used, it is used to level off the highs and lows, so the overall volume can be higher without peaks that would distort. When there’s more volume, there’s more data.

          Reply
          • Hamranhansenhansen says:

            I don’t think the audio volume has much to do with it at all. That is just the amplitude of the waveform. Noise is the main issue.

            How small you can make a file with lossless compression mostly has to do with how random the data is, not how loud the audio is. More randomness, less compression.

            Some bitstreams look like this, not very random:

            1111111111000000000011111110000000000011

            … so you can compress the above to:

            10×1, 10×0, 7×1, 11×0, 2×1

            … and make a much smaller file.

            Some bitstreams look like this, very random:

            1001101010010100110011001010101001010101

            … which compresses to:

            1, 2×0, 2×1, 0, 1, 0, 1, 2×0, 1, 0, 1, 2×0, 2×1, 2×0, 2×1, 2×0, 1, 0, 1, 0, 1, 0, 1, 2×0, 1, 0, 1, 0, 1, 0, 1

            … and makes a much larger compressed file.

            Notice that the 2 raw bitstreams above are both 40 characters, but one made a tiny compressed file and one made one that is much larger.

            What is random in audio is *noise*. If you have heard “white noise” it is just random sound. So if you have some audio with some noise in it (say from a turntable rumble, or vinyl pops, or the inherent distortion in LP’s) that is not going to lossless compress well. The CD version of that track will have less noise, no turntable rumble, less or no distortion, no vinyl pops, so it will lossless compress much better.

            Some electronic music has a lot of deliberate noise in it. A synthesizer part may be made up of mostly noise. With metal or rock music, a distorted electric guitar has a lot of noise. So if you lossless compress some electronic or metal music, it is going to make much larger files than many other genres of music. Rammstein is going to require a larger bitrate than Bieber, because Rammstein is noisier, more random, harder to data compress.

            Reply
  3. Andrew says:

    Average volume and bit rate are not related when it comes to PCM encoding. The bits are used to describe the waveform, but it’s incorrect to state that a waveform with a larger amplitude requires a larger number of bits to encode. Redbook Audio (the audio CD) standard defines the bit rate to be 1411.2 kb/s. This is derived from 16 bit quantization, 2 channels and 44.1 kHz sampling frequency.
    http://en.wikipedia.org/wiki/Pulse-code_modulation
    http://en.wikipedia.org/wiki/Red_Book_(CD_standard)

    File size compression, similarly, shouldn’t be dependent upon volume. Size compression should be primarily influenced by waveform complexity, which is supported by the differing rates reported in the post.
    http://en.wikipedia.org/wiki/Audio_compression_(data)

    Reply
    • transfers says:

      “Average volume and bit rate are not related when it comes to PCM encoding.”
      Correct for PCM encoding which is constant bit rate, but Apple Lossless is not PCM, it is variable bit rate.

      Reply
  4. ThrillerUSA says:

    Anymore guys? Great stuff.

    Why do individual instruments like flutes and French horns in Princess Leia’s Theme from the Star Wars Soundtrack become more clear and separated, more lifelike, when a 44.1 Apple LossLess file is made from the 44.1k/16 AIFF CD then played back though iTunes via a high quality outboard USB DAC?

    And what is this about an Apple LossLess file being easier to play through an iOs device? Is this because the Apple LossLess “language” is better read by Apple devices kinda like Apple ProRes HQ once converted works awesome in Final Cut Pro?

    Many thx, Mark

    Reply
    • kirk says:

      Are you saying more clear and separated than a CD? What are you comparing it to, playing the CD on a Mac or PC? If the CD isn’t going through a DAC, it depends on the quality of the soundcard and DAC in the computer.

      Reply
      • ThrillerUSA says:

        To be clear,

        If I import an AIFF track from a CD via my MacBook Pro internal DVD-R drive then convert that AIFF file using XLD to a 44.1 Apple LossLess file; both tracks being sourced from the same internal solid state hard drive, both being played through iTunes (no Pure Music or Amarra), both being outputted to an Apogee Duet 2 (192k capable async USB DAC), listening with either flagship full-size headphones or high-end two channel home stereo; without fail the Apple LossLess versions have more realistic sounding instruments and separation between individual artists over the same track in AIFF.

        It is not a subtle difference.

        In Final Cut Pro, transferring all video files to Apple Pro Res before editing allows more real-time effects and cleaner, faster forward and reverse play inside a timeline. Everything works better.

        The same phenomenon happens when I transfer a 88k, 96k or 192k FLAC files to Apple LossLess – all things being equal – the Apple LossLess track played through iTunes (an Apple product like Final Cut Pro is an Apple product), a layer of sheen is lifted form the music like a cloth speaker grill is being removed from a speaker. The plucking of an acoustic guitar becomes more lifelike, every aspect of a performance sounds more realistic.

        In higher resolution stuff like Beck’s 88.2k Sea Change album, Track #9 “Already Dead” – the Apple LossLess version sounds like a guitarist in the same room sitting on a stool to your right whereas the AIFF or FLAC versions (FLACs being played through Pure Music via RAM – or – Fidelia or Amarra via I don’t know what) sound like a very good song being played through a stereo. But not lifelike.

        So I was wondering if maybe Apple is using some codec or better terminology which is read ‘more natively’ through iTunes, giving it a more efficient reading or one less conversion of sorts compared to playing the AIFF track off the same hard drive.

        On the Apple LossLess page in WikiPedia there is a statement (THE LAST SENTENCE APPLIES HERE): “Apple claims that audio files compressed with its lossless codec will use up “about half the storage space” that the uncompressed data would require. Testers using a selection of music have found that compressed files are about 40% to 60% the size of the originals depending on the kind of music, similar to other lossless formats.[2][3] ****Furthermore, the speed at which it can be decoded makes it useful for limited-power devices such as iOS devices.[4]****”

        “The speed in which it decodes” does not suggest file size or storage considerations but the ease in which an iTouch can play an Apple LossLess file vrs an AIFF file.

        What do you think?

        Thx, Mark

        Reply
        • kirk says:

          An AppleLossless file is a bit-perfect equivalent to the original file (CD, WAV, AIFF, FLAC, etc.).

          It’s possible that Apple has the necessary codec on a chip, rather than as software, which would enable the decoding to occur more quickly and with less power usage.

          Reply
          • ThrillerUSA says:

            Oh really?

            So Apple LossLess in iTunes might be playing from a chip – and an AIFF might be playing through software.

            Very interesting.

            Reply
          • ThrillerUSA says:

            Joe, ABXer is a cool little tool.

            Conclusion after an hour of testing; through ABXer I’m hearing the same sonic improvements in converted Apple LossLess over the same tracks in AIFF 1411.2 kbps. Same with A/B comparisons between native FLAC 96k tracks and their converted 96k Apple LossLess equivalents.

            This would suggest iTunes has nothing to do with Apple LossLess tracks sounding more detailed than the same AIFF or FLACs because of some communication improvement between like-minded Apple algorithms or whatever they should be called.

            But is ABXer potentially tapping into the same Apple LossLess “chip” suggested by Kirk or other processes found inherent to my 2011 MacBook Pro hardware?

            Could my Apogee DAC, a company with solid links to Apple for many years in pro digital conversion, somehow prefer converting Apple LossLess over AIFF? Or, is the conversion strictly being done inside the computer and the Apogee DAC has nothing to do with AIFF vrs. Apple LossLess conversion?

            To my ears there are distinct improvements when playing Apple LossLess files from a Mac, I wish I could figure out why.

            Thanks again for your input guys.

            Reply
          • kirk says:

            The results surprise me. For me, lossless is lossless. Once the decoding is done (which is, indeed, done on the computer), they should be bit-for-bit.

            Reply
          • ThrillerUSA says:

            Kirk I know, I wish all lossless sound the same because I wouldn’t have to worry about this anymore. But they don’t all sound the same, not in iTunes.

            I thought to import a store bought CD as .aiffs I was done – hard disk space don’t care. But the converted Apple LossLess alternative blew the cloned .aiff out of the water. It sucks because I’ve spent the last two days repeating trials and comparisons and frankly I’m over it. But if I stopped before seeing it through I would have to start over again learning the snippets of references, plus it would keep me up all night pondering the situation.

            After 15 minutes fiddling with the ABXer I was 100% accurate deciphering a 96k FLAC track (Chesky’s ‘World’s Greatest Audiophile’ thing, Track #2 “Isn’t She Lovely”) over the same file converted to Apple LossLess. It’s stupid, the ALAC has a detail not found playing the other formats in iTunes. I’d love to know why.

            I think Apple has made a custom codec for it’s music playback scheme that is in some way being more easily read and played back by it’s own proprietary engine, just like Apple Pro Res converted files smoke every other quicktime codec when working within FCP. The two are speaking the same language, the rest are speaking the same language but have foreign accents.

            Apple loves to operate within themselves, create things that work and crush all comers. Why would their pride and joy iTunes be any different? Apple LossLess? It’s even in the name. Comparing apples with apples.

            To my ears their own lossless codec sounds better in their own playback engine, it’s just a simple fact.

            So to be so wordy.. cheers

            Reply
          • Joe says:

            Yes – very interesting indeed! What results did you get from the ABX test? It would be good to share such results on some of the audio tech forums to see if anyone has an idea why this may be.

            Reply
          • Joe says:

            okay ignore my last post… 100% accuracy eh! That’s bizarre! :) at least the ALAC is both better and takes up less space for you ;)

            Reply
    • eCo says:

      The difference you hear MAY be real BUT in this case would probably come from the ReplayGain :
      http://en.wikipedia.org/wiki/ReplayGain

      Apple uses its own technology called SoundCheck :
      http://support.apple.com/kb/HT2425

      When you convert from AIFF to ALAC, iTunes analyzes the audio and insert the Sound Check tag in the MP4 container.

      When you compare the AIFF to the ALAC, the player applies the ReplayGain (Sound Check) to the ALAC output but not to the AIFF output.

      When doing an ABX, it is CRUCIAL to have the same gain on A and B, else any tiny change in the volume may be easily detected, even by non golden ears…

      Reply
      • kirk says:

        That’s a good thought, but that only applies if you do have Soundcheck turned on in the iTunes preferences.

        I do agree that you need to make sure the volume is exactly the same, but if Soundcheck is off, there shouldn’t be an issue. (And, in my experience, Soundcheck should _always_ be off.)

        Reply
    • kirk says:

      Less battery than what? A WAV or AIFF? If so, it’s because the files are smaller, hence there is less data being read from the flash memory.

      Reply
  5. kirk says:

    I doubt it would be chip-based on a computer, where battery usage is less of an issue. It could be on an iOS device, but I don’t know how one would find out. Since Apple makes their own processors, there’s no way to know, but it wouldn’t surprise me that they manage to off-load some common tasks to a dedicated chip.

    Reply
  6. Jazz1 says:

    I found this thread through another thread on the forum. So, is there some consensus that I’d be better off converting my AIFF files to Apple Lossless, or do I have to re-rip all my CD’s straight to Apple Lossless?

    Reply
    • kirk says:

      You definitely shouldn’t re-rip. AIFF is uncompressed, and Apple Lossless is compressed, but lossless. Convert from AIFF to Apple Lossless, and you won’t lose anything.

      Reply
      • mikey says:

        To be precise…
        You can go to & from PCM (i.e. AIFF & WAV) to lossless (i.e. ALAC) at will: the files can be compressed & uncompressed back and forth inside iTunes by the user whenever they feel like it, without ANY loss of quality whatsoever in the process.
        As previously said above; just the same as any files inside ZIP files can be zipped (compressed) & unzipped (uncompressed) back and forth without any data loss on said files.

        That’s one of the things that makes using lossless so appealing: the original PCM data is all there, just 40-60% of the size, but you also get the additional benefit that lossless metadata tagging is available, which isn’t in WAV, and not as good on AIFF.

        Another reason to pick ALAC for your lossless format over FLAC’s, is that it’s the ONLY lossless format Apple support _natively_ in iTunes (and other system apps) for transferring content to & from their portable devices (i.e. ALL iPods and iOS devices). And as ALAC is open licensed now, nearly everyone now supports it, so ALAC files will work on virtually ALL other platforms like Android/WinPhone/Win/Linux (it’s essentially a codec of the ubiquitous MP4 container format, you see ;-).

        Whereas Apple will NEVER _natively_ support FLAC on their own playback devices, so ALAC gives you the best compatibility of both worlds: it works on ALL devices, and especially on Apple’s _native_ audio integration!

        Compared to FLAC, which cannot be used with iTunes software, unless you use third-party non-iTunes software (like VLC player), which then won’t integrate with other aspects of the massively popular Apple ecosystem that a gazilion third-party devices are now incorporating into what is becoming a de-facto standard, e.g. connected “MFI” (Made For iPod/iPhone/iPad) equipment like speakers, “iTunes In The Car” car audio systems, and whatever smartwatch, smarthome (perhaps something like “iTunes In The Home” home automation systems we’re highly likely to see Apple offer SDK’s for in future years), etc.

        Apple aren’t going anywhere. But even if they did, ALAC’s will carry on working across other manufacturers products.

        So think longterm, and understand the LONGTERM advantages of choosing ALAC now.

        Reply
        • mikey says:

          …oops, those should have said “*iOS* In The Car” and “*iOS* In The Home”.

          In summary:
          FLAC’s do not work simply in iTunes AT ALL, period. Ignore any of the third-party, so-called ‘iTunes plugins’ (for iTunes software on your Mac/PC only) that promise ‘limited FLAC integration’, as they are so highly limited as to be useless. And even if they did work on Mac/PC iTunes software, the FLAC’s certainly will NOT import from computer iTunes to iOS iTunes on your iOS device anyway, making them pointless.

          Compared to ALAC’s which will work in virtually EVERYTHING on other platforms (i.e. iTunes, any other audio database software, or any other audio software).

          If ever there was a no brainer, then this surely would be one.

          Reply
  7. Tom Duffy says:

    Consider this (likely) possibility:
    iTunes plays all files using QuickTime as the engine.
    When playing ALAC files, QuickTime instructs CoreAudio to send the audio at the correct Sampling rate to the USB DAC and feeds the audio unchanged.
    When playing AIFF files, iTunes or QuickTime assumes that the file is in a non-standard sample rate, and consequently re-samples it to 44.1kHz before sending the data to the USB DAC.
    i.e. ALAC files are getting favorable treatment.
    There is no way to see when the QuickTime SRC is engaged, and under what circumstances.
    This would certainly explain the “veil” on the AIFF files, that is how I often describe SRC’ed audio.

    Tom.

    Reply
    • kirk says:

      Well, to prove that, you can test an AIFF at a resolution higher than 44.1, and see what your DAC receives it as. Pretty simple.

      Reply
      • ThrillerUSA says:

        Kirk, could you describe ‘test’?

        I’m not quite getting the process; import from cd as a higher resolution AIFF and test the sound quality? No.

        Change the resolution manually in the midi settings to maybe 88.2 then play an AIFF checking the rate at the DAC? Why wouldn’t the DAC ‘show’ whatever you send it from the midi settings?

        Just can’t quite wrap my head around the purpose here.

        Thx in advance for any info.

        Reply
      • Tom Duffy says:

        Yes, there is a simple way to test for this if your external DAC has LEDs for current FS. My setup has the master clock external to the computer, so the OS isn’t allowed to change the FS at all, so I can’t look into this as soon as I’d like (and I am curious).

        I know this use scenario has similar problems on Windows; it’s only with Windows 7 and WASAPI exclusive mode that the application is able to get the OS to lock the FS to the rate it wants to get bit-perfect data out of the computer to an external DAC. Needless to say, iTunes (actually QuickTime) on Windows doesn’t use this mode.

        Tom.

        Reply
        • ThrillerUSA says:

          I’m curious Tom for your clocking do you by chance use a Big Ben, Antelope, MSB, home-made…?

          Reply
          • Tom Duffy says:

            personal recording studio, TASCAM DM-4800 with FireWire card into the computer (use both Mac and PC). The mixer is the clock master. It’s not up to stand-alone clock standards, but since it’s the center of the studio, everything goes into it.

            Tom.

            Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply