Re-encoding - Is there such a thing?
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
dandy72 wrote:
he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with.
OK but how about this: re-encode everything anyway, then compare the loss between the 320kbps version and the new version. If there's a lot of loss, keep the big version. Audio comparison tools exist, so this wouldn't involve anything fancy.
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
I always encode everything to 128kbps. This comes from a time when my HD was only 500 GB (ancient times) and it was full. It's still very relevant for my (old) 160 GB MP3 player today. This may sound like I'm really old skool, or hipster maybe, but my music tastes aren't always on streaming platforms such as Spotify or Bandcamp. I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike. Besides, the brain is great at filling in missing parts. The soundtracks back in the (S)NES days sounded like actual orchestras to me ;) Anyway, "upcoding" isn't possible as far as I know. Tried it sometime, but it gets glitchy. I can't imagine "upcoding" and then decoding back is good for your quality. I'm afraid your friend is out of luck :( But couldn't he just try to decode the 256 ones back to 128 and leave the 320 alone? Or decode the 320 to 256 or 192 to save some space while still having decent quality? He should also check VBR (Variable Bit Rate), which is kind of what you want, but not completely. It will work for the original 320, but probably won't make the "upcoded" stuff better. With VBR you get like 128 (or even less) at the quiet parts and maybe 320 at loud parts with lots of instruments, and everything in between, basically. Your bit rate with VBR can be something like 213kbps because it's an average of the various parts. It's the best of both worlds although, as said, I don't use it myself.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
Chances are very good that re-encoding (up or down) introduces more losses; however those losses may be acceptable. As suggested elsewhere, he could try downward re-encoding and see if he can notice the difference. If he uses a variable bitrate with target 128, he'll get the smaller size and perhaps less loss.
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
The easiest solution (I have actually done similar for bulk video processing) is to, for each file (named SONG.mp3 in my example below): 1. Convert to raw audio samples (the type you can cat to /dev/dsp, for example): SONG_ORG.pcm 2. Convert to 256kps, then convert that to raw audio samples: SONG_256KPS.pcm 3. Convert to 128kps, then convert that to raw audio samples: SONG_128KPS.pcm At this point you'll have three uncompressed (raw audio) versions of the song. If you specified the same sampling rate for all of them they should all be the same size. Now this is the slightly more difficult part. Write a program that takes two files and finds the statistics on the bytes in both files (avg, mean, median, variance, std-dev, frequency, distribution, etc) AND finds the statistics on the deltas between the two files taken together (some programs can do this). Running this program on SONG_ORG.pcm and SONG_256KPS.pcm would show you how large the difference in sound is between the two files. If it is too large (experiment with the threshold) then you cannot re-encode to the smaller bitrate format because too much information was lost. If the difference is small then you can. The only time-consuming part will be writing the program to examine PCM samples and give stats on the deltas. When I did this with video, I used ffmpeg to generate stills and image-magick to generate stats from those stills, and let it run over the weekend on all the videos I was checking. You can use sox/liblame to do the PCM/mp3 generation, but I don't know of a program that does for sound what image-magick does for images.
-
I always encode everything to 128kbps. This comes from a time when my HD was only 500 GB (ancient times) and it was full. It's still very relevant for my (old) 160 GB MP3 player today. This may sound like I'm really old skool, or hipster maybe, but my music tastes aren't always on streaming platforms such as Spotify or Bandcamp. I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike. Besides, the brain is great at filling in missing parts. The soundtracks back in the (S)NES days sounded like actual orchestras to me ;) Anyway, "upcoding" isn't possible as far as I know. Tried it sometime, but it gets glitchy. I can't imagine "upcoding" and then decoding back is good for your quality. I'm afraid your friend is out of luck :( But couldn't he just try to decode the 256 ones back to 128 and leave the 320 alone? Or decode the 320 to 256 or 192 to save some space while still having decent quality? He should also check VBR (Variable Bit Rate), which is kind of what you want, but not completely. It will work for the original 320, but probably won't make the "upcoded" stuff better. With VBR you get like 128 (or even less) at the quiet parts and maybe 320 at loud parts with lots of instruments, and everything in between, basically. Your bit rate with VBR can be something like 213kbps because it's an average of the various parts. It's the best of both worlds although, as said, I don't use it myself.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike. Besides, the brain is great at filling in missing parts. The soundtracks back in the (S)NES days sounded like actual orchestras to me ;)
For some reason that just reminds me of this scene: Everybody Loves Raymond - Vinyl vs CDs - YouTube[^]
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
The MP3 codec is a lossy format. Unfortunately, there is no way back to the original file size without loss. The only real way to fix it would be to encode them at the desired bitrate from uncompressed WAV files.
-
Sander Rossel wrote:
I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike. Besides, the brain is great at filling in missing parts. The soundtracks back in the (S)NES days sounded like actual orchestras to me ;)
For some reason that just reminds me of this scene: Everybody Loves Raymond - Vinyl vs CDs - YouTube[^]
Fun fact, in 2019, vinyl revenue surpassed that of CDs for the first time since 1986. CDs still sold more in absolute numbers, but vinyl is more expensive :) I say, bring back the VHS! ;p
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
-
dandy72 wrote:
he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with.
OK but how about this: re-encode everything anyway, then compare the loss between the 320kbps version and the new version. If there's a lot of loss, keep the big version. Audio comparison tools exist, so this wouldn't involve anything fancy.
-
The easiest solution (I have actually done similar for bulk video processing) is to, for each file (named SONG.mp3 in my example below): 1. Convert to raw audio samples (the type you can cat to /dev/dsp, for example): SONG_ORG.pcm 2. Convert to 256kps, then convert that to raw audio samples: SONG_256KPS.pcm 3. Convert to 128kps, then convert that to raw audio samples: SONG_128KPS.pcm At this point you'll have three uncompressed (raw audio) versions of the song. If you specified the same sampling rate for all of them they should all be the same size. Now this is the slightly more difficult part. Write a program that takes two files and finds the statistics on the bytes in both files (avg, mean, median, variance, std-dev, frequency, distribution, etc) AND finds the statistics on the deltas between the two files taken together (some programs can do this). Running this program on SONG_ORG.pcm and SONG_256KPS.pcm would show you how large the difference in sound is between the two files. If it is too large (experiment with the threshold) then you cannot re-encode to the smaller bitrate format because too much information was lost. If the difference is small then you can. The only time-consuming part will be writing the program to examine PCM samples and give stats on the deltas. When I did this with video, I used ffmpeg to generate stills and image-magick to generate stats from those stills, and let it run over the weekend on all the videos I was checking. You can use sox/liblame to do the PCM/mp3 generation, but I don't know of a program that does for sound what image-magick does for images.
That sounds like the sort of analysis I had in mind. However I'm not the one with the vested interest in solving that "problem" :-) so I'm not gonna be spending any time coding this. I'd be curious to know whether someone's already written that sort of thing... The more I read about this, the more I think my buddy needs to re-rip everything from the original source, or live with the extra space requirements. Storage is cheap nowadays...
-
The MP3 codec is a lossy format. Unfortunately, there is no way back to the original file size without loss. The only real way to fix it would be to encode them at the desired bitrate from uncompressed WAV files.
Jason Hutchinson wrote:
The MP3 codec is a lossy format. Unfortunately, there is no way back to the original file size without loss.
Well, the file started life as 128kbps, then was converted to 320kbps. The question is, how much loss would be incurred when going from 320 back to 128, and comparing that version with the original that already was at 128. Even though, I realize, he no longer has it. But it would be an interesting experiment one way or another - and hang on to all versions each step of the way so they can later be compared.
-
Send him here: mp3ornot.com[^] and if he doesn't score (say) 5/5 then he may as well give up, and encode them all to 128. I got the first 2 right, but failed on the third (didn't like the sound anyway) so stopped. I am not an audiophile.
That's an interesting test, although they really need more than just the one sample song. Some recordings can sound fine at 128kbps, and others might sound *terrible* at that resolution. But then I've only tried this with my desktop speakers with the window open, traffic going by and a fan running. Not exactly a great listening setup.
-
That's an interesting test, although they really need more than just the one sample song. Some recordings can sound fine at 128kbps, and others might sound *terrible* at that resolution. But then I've only tried this with my desktop speakers with the window open, traffic going by and a fan running. Not exactly a great listening setup.
-
I always encode everything to 128kbps. This comes from a time when my HD was only 500 GB (ancient times) and it was full. It's still very relevant for my (old) 160 GB MP3 player today. This may sound like I'm really old skool, or hipster maybe, but my music tastes aren't always on streaming platforms such as Spotify or Bandcamp. I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike. Besides, the brain is great at filling in missing parts. The soundtracks back in the (S)NES days sounded like actual orchestras to me ;) Anyway, "upcoding" isn't possible as far as I know. Tried it sometime, but it gets glitchy. I can't imagine "upcoding" and then decoding back is good for your quality. I'm afraid your friend is out of luck :( But couldn't he just try to decode the 256 ones back to 128 and leave the 320 alone? Or decode the 320 to 256 or 192 to save some space while still having decent quality? He should also check VBR (Variable Bit Rate), which is kind of what you want, but not completely. It will work for the original 320, but probably won't make the "upcoded" stuff better. With VBR you get like 128 (or even less) at the quiet parts and maybe 320 at loud parts with lots of instruments, and everything in between, basically. Your bit rate with VBR can be something like 213kbps because it's an average of the various parts. It's the best of both worlds although, as said, I don't use it myself.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I don't really hear the 128 vs. 320 difference though. Maybe with headphones, but not from my laptop speaker or earplugs on my bike.
:-D That much is a given. Laptop speakers are notoriously bad (and I laugh at laptops that have built-in Harman Kardon speakers). Steve Jobs has also done a *fantastic* job at lowering expectations given the hardware he hawks. I'm no audiophile by any stretch, but depending on the material, I'll almost *always* immediately make the distinction between 128 and 320kbps. 256 is where I'll typically start to get it wrong.
-
There is more than one sample - by some magic, if one waits, the sample changes on next play - don't ask me how that works! I think you have to do all 3 listens, then select an answer - then the clip changes!
I hit refresh about 20 times, and the same sample keeps coming up. Maybe you do have to listen to them all, rather than immediately jumping to step 2. [Edit] Ok, my mistake was hitting Refresh to try to get a new sample. It seems to restart the whole thing, so refresh is entirely pointless...
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
I think you can tell by looking at the frequency content. It's easy to tell the difference between an "it started as an MP3" file and a "it started as a WAV" in my audio noise clean-up software because the spectrum for the MP3 has a brick-wall low pass filter well below the Nyquist frequency for the file's sample rate. That frequency is probably lower for lower-resolution MP3 files. (But no, I don't think I've ever checked this. And though I'm working from home, I risk far too much distraction from "I'm supposed to be working now" if I turn on the home computer and its associated audio editing tools to run some tests.)
-
I think you can tell by looking at the frequency content. It's easy to tell the difference between an "it started as an MP3" file and a "it started as a WAV" in my audio noise clean-up software because the spectrum for the MP3 has a brick-wall low pass filter well below the Nyquist frequency for the file's sample rate. That frequency is probably lower for lower-resolution MP3 files. (But no, I don't think I've ever checked this. And though I'm working from home, I risk far too much distraction from "I'm supposed to be working now" if I turn on the home computer and its associated audio editing tools to run some tests.)
I wondered if the frequency spectrum would be enough to indicate the bit rate, as although I knew that MP3 encoding 'threw away' bits of the sound, I didn't know whether that would show clearly on a spectrum - so I just took the same 5s clip from the sound track to Clockwork Orange (The Thieving Magpie) which I know contains some well defined high-frequency bits (a flute or somesuch - I used this track to compare recordings onto audio cassettes many years ago, to establish which tape quality (cost) level was needed to avoid unacceptable loss). I loaded the orignal WAV file from CD into Audacity, and did a spectrum. Then saved as MP3 at a variety of bitrates. and did the same. Without being able to load pictures here, I can table the maximum frequency seen in the plots for various bit rates, as it is very clear there is a pattern:
bit rate -100dB freq (Hz) Full (WAV) 21,300 320 kbps 20,100 256 19,400 128 16,600I picked the freq at which the signal went below -100dB, as that corresponded roughly with the visual scale on the plot (which only goes down to -90 by default). The cutoff was well-defined, and if there is a place to put them, I can supply screen shots. So one could take a resampled file and, if its frequency cutoff (of maybe a suitable bit) was below, say, 18kHz, one could judge that it came from a 128kbps original. It would be a lot of work to do that for all files, of course. You really need a tool that measures in one go the frequency cutoff. What surprised me was that there was very little difference in the spectrum apart from the upper end - but of course, that is where the sample rate required for faithfull reproduction is greatest, so where the greatest reduction in file size can be obtained. Now off to look at the wavefoms in more detail... I, of course, am retired, so have nothing better to do - and it was fun.
-
I wondered if the frequency spectrum would be enough to indicate the bit rate, as although I knew that MP3 encoding 'threw away' bits of the sound, I didn't know whether that would show clearly on a spectrum - so I just took the same 5s clip from the sound track to Clockwork Orange (The Thieving Magpie) which I know contains some well defined high-frequency bits (a flute or somesuch - I used this track to compare recordings onto audio cassettes many years ago, to establish which tape quality (cost) level was needed to avoid unacceptable loss). I loaded the orignal WAV file from CD into Audacity, and did a spectrum. Then saved as MP3 at a variety of bitrates. and did the same. Without being able to load pictures here, I can table the maximum frequency seen in the plots for various bit rates, as it is very clear there is a pattern:
bit rate -100dB freq (Hz) Full (WAV) 21,300 320 kbps 20,100 256 19,400 128 16,600I picked the freq at which the signal went below -100dB, as that corresponded roughly with the visual scale on the plot (which only goes down to -90 by default). The cutoff was well-defined, and if there is a place to put them, I can supply screen shots. So one could take a resampled file and, if its frequency cutoff (of maybe a suitable bit) was below, say, 18kHz, one could judge that it came from a 128kbps original. It would be a lot of work to do that for all files, of course. You really need a tool that measures in one go the frequency cutoff. What surprised me was that there was very little difference in the spectrum apart from the upper end - but of course, that is where the sample rate required for faithfull reproduction is greatest, so where the greatest reduction in file size can be obtained. Now off to look at the wavefoms in more detail... I, of course, am retired, so have nothing better to do - and it was fun.
Thanks for confirming my hunch. WAV file from CD should be sampled at 44.1KHz, which puts Nyquist at 22.05KHz -- pretty close to the 21,300Hz you see. My older ears don't hear the difference between 128kbps and 320kbps unless I'm paying close attention.
-
Someone's come to me with what I thought was a good question. He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps. X| Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files. The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that *were* originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with. Obviously this isn't "audio fingerprinting" like [MusicBrainz Picard](https://picard.musicbrainz.org/) can do. And I can't come up with the right keywords for googling.
You can compare decoded raw bitstreams with tools like Audacity but imho it is unnecessary. Re-encoding with VBR (Variable bitrate) encoding would be the way to go. It will use lower bits when there is less sound information, and will use your maximum provided bitrate when it actually needs it. Also, I would strongly advise to migrate from mp3 to a better format unless you're hardware locked. 128 kbps opus is said to be transparent (almost indistinguishable from uncompressed form to 99% ears) while 80-96 kbps opus is somewhat equivalent to 320 kbps mp3. And the format is royalty-free with wide support from various OSes.
