|
Yeah, I did the same, especially because I used to have a 500 GB HD back in the day, which was full (with games and music).
For my MP3 player it's nice to have everything in 128 kbps as well.
However, I can't quite pinpoint it, but I notice a difference when I listen to a high quality recording or my own 128 kbps, especially on my headphones.
So since storage is no longer an issue, I decided to make my own collection high quality as well.
|
|
|
|
|
Quote: especially on my headphones
Ah! There's your problem right there! I never use headphones and play everything on my computer speakers (or the aforementioned car) so the quality difference really doesn't show up. 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
The difference also depends on the kind of music you listen to.
Lo-fi basement black metal, not so much, but well recorded classical music, yes please! 
|
|
|
|
|
I can definitely hear a difference between 128 and 192 kbps, 128 is much flatter.
224 I can also hear the difference to sometimes, depending on the music. But I cannot distinguish the difference to the next step 320.
So I record everything to 320 so that I'm sure I'm above the threshhold of my hearing.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
Yeah, right.
I used to give out a set of some thirty music samples of different musical categories, coded and decoded in 2-3 different formats, along with an ABX program. ABX is for double-blind-testing: Two presumably identical sound files, but encoded/decoded by different methods - such as different bitrate, or MP3 and AAC-LE - as "A" and "B". The ABX-program selects randomly one of them as "X", and the test person can switch among the three, to determine whether "X" is a copy of "A" or a copy of "B". When his guess is made, the program makes another random "X" selection for the test person to compare and make his guesses, typically 20-30 times. The program logs how many times the guess was correct. If the guess was correct 10 out of 20 times, we can conclude that the test person did not hear any difference between "A" and "B".
As all files were decoded back to "wav" format, the test person did not know which processing they had been through. Even if I were present at the listening, I couldn't tell which of the files were, say, original uncompressed, MP3@128 or MP3@192 - they were named e.g. Fanfare-0923.wav, Fanfare-7226.wav
and Fanfare-8234.wav. I would have to check my logs to see which is which, and made no attempt to memorize it.
I gave these samples away to a couple dozen of golden-ears guys, making statements very similar to yours, inviting them to do the listening on their very best equipment, under the most perfect listening conditions they could provide, and then come back with the ABX logs showing how well they managed to identify X correctly. The problem: Even after pushing the golden-ear guy several times, asking when he had completed the listening, not one of them dared to come back to me with the ABX logs. A few times, they might claim that "With some music samples it is easy to spot, but others are more difficult" - but unwilling to tell which are "easy", and unwilling to provide the ABX logs for those ...
I never got a single ABX log back, no matter how much I pushed.
But then: This was a true double-blind test. Most times when people claim to have made double-blind listening, a little questioning reveals that it certainly isn't. Maybe it isn't even guaranteed to be single-blind...
Usually, I challenged the test persons for a more difficult test: Play "X" only, without comparing it to "A" or "B", and tell me what kind of processing that sound file has been through. Does the "flatness" of the sound reveal that it has been MP3@128 compressed? This is a much harder test than telling that "X" is identical to "B". I never made a single person even try himself on that test.
I am happy that you believe that you can hear the difference between MP3@192 and MP3@224. At least when you know it. There is placebo so strong that it works, even if you don't believe in it.
|
|
|
|
|
Your music was once an analog signal. When they made the CD they cut it in little pieces 44100 times per second, recorded the value at each point and wrote it on the CD. Now you come and record 320000 values each second. Your ripper program is going faithfully repeat the same value 7 times without any benefit for music quality.
This is the executive summary for a tl;dr see Digital Audio Basics: Sample Rate and Bit Depth | PreSonus[^]
Mircea
|
|
|
|
|
44.1K samples per second is different than a 320kbps bit rate.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Now you are mixing up things completely!
For taking the very basics: 44100 is the number of samples, each sample being two 16-bit values. The bit rate is a 1411 kilobits/sec - more than four times 320 kilobits/sec.
Those 320 kbps has nothing to do with the sample rate or the sample width. We are talking about compressed data, like a .zip file. To make a super-trivial example: If there is a five second pause in the music, 5 * 44100 * 2 * 16 = 7055 kbits, in the CD format. In a compressed file, you can rather store this with a code that means "repeat sample value 0 for both channels 220500 times", using far less than 7 megabits.
The MP3 coding is using quite different techniques than counting repeated sample values, and it is't giving you back a perfect copy of the original uncompressed sound (so it cannot be directly compared to zip). One of the basic ideas between the MPx compression is to identify which details you wouldn't hear anyway, they will drown in other sounds. The higher you set the bit rate, the more such inaudible detals are considered for compression. An MP3@128 file has "simplified" the sound more than an MP3@224 file - but if you couldn't hear anyway the details that were removed, it is just a waste of space.
One more thing: Contrary to common belief, MP3 encoding is not standardized. MP3 decoding is. Given an MP3 file, all decoders will produce exactly the same sound. But given an .wav file, the encoder has a multitude of alternate ways to generate a valid MP3 file; they will generate different files, all decoding to approximately the same sound, some very close to the original .wav file, some that could have audible differences. Encoders use a whole back of tricks, often proprietary, for determining the best alternative. E.g. they may try out several alternatives, decode them back and compare to the the original file. The encoding alternative that differs the least from the original is chosen for the encoding. A simpler, poorer quality encoder may make a single attempt at something that resembles the original file, and leave it at that.
So, the sound quality of an MP3 file strongly depends on the encoder. Neither 128 kbps nor 224 kbps sets the quality. A top rate encoder at 128 kbps may produce a better result than a mediocre one at 224 kbps.
|
|
|
|
|
|
The 320kbps does not refer to the sampling rate, but the data transmission rate. I just calculated the transmission rate for a particular flac file and it is 1961kbps. Encoding a file with the mp3 codec does not change the sampling rate, but instead modifies the data based on how we hear sound in order to reduce the data size without reducing the apparent sound quality much.
|
|
|
|
|
I stand corrected!
320kps is the bit rate while 44.1k is the sampling rate. What's the difference? Each sample is 16 bits wide and considering that there are 2 channels that makes the bit rate 32 * 44.1k = 1411.2kbps. MP3 compresses it down to 320kbps.
That should teach me not to post before researching 
Mircea
|
|
|
|
|
|
Sander Rossel wrote: I don't really know what those values mean, but 320 kbps == good quality.
Well, usually it is so. Even the poorest MP3 encoder manages to get a decent result at that bit rate.
A high quality encoder can use more CPU power and smart analysis to evaluate alternative ways of encoding the same sound, and will give a decent sound quality at far lower bit rates. With the best encoder, most kinds of music can be encoded at 128 kbps with a quality that makes it practically impossible to distinguish from higher bit rates (in true double-blind tests, that is).
MP3 (/MP1, MP2) was the very first widespread application of what is called "psychoacoustic encoding". The waveform is not compresses as a waveform; rather, the method tries to identify how we experience the sound, and encode that. So the developers didn't have extensive experience, and a few kinds of sounds are not handled that well. The classical example is castanets - used by everyone who wants to debunk MP3, even if that famous sound sample is the only time ever they heard castanets.
By and by, the encoder guys learned new tricks for smart encoding of even castanets, and of other sounds. The well-known open source LAME encoder started out as a very simplistic encoder, making MP3 files far inferior to commercial counterparts. But over the years, lots of sound experts contributed their shares - LAME is an excellent example of a very successful crowd development project. Gradually, the sound quality (at a given bitrate) improved, and became as good, or nearly so, as commercial coders (which has also improved a lot over the years).
Experience with "difficult" sounds like castanets taught the developers "If we only had a function code so-and-so for the compressed file, it would be much easier!" So we got AAC, which may be considered an extension, or maybe more correctly: a re-implementation of MP3, with an extended set of function codes. Where MP3 requires a whole set of codes to represent some sound, AAC may be able to do it with a single code, requiring a lot fewer bits. So AAC can represent sound with the the same sound quality as MP3 can, but at half the bit rate. And, it handles castanets well!
Bottom line: You can't say anything definite about sound quality from the bit rate. It all depends on the encoder. (And even more on the method - MP3 or AAC.)
|
|
|
|
|
I did not know that, interesting 
|
|
|
|
|
|
Policeman in curse battered astronomer! (10)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
modified 7-Dec-20 3:51am.
|
|
|
|
|
Policeman => Cop
battered => anagram
in curse => ernicus
astronomer => Copernicus
// TODO: Insert something here
|
|
|
|
|
And you are up tomorrow!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Good one
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
I second that
|
|
|
|
|
thirded
|
|
|
|
|
I've been writing IoT stuff a lot lately because I've been building them for work, and for fun for that matter as of late.
They're really great, but they make it a challenge for me to come up with content. I feel like my articles are necessarily shorter, more like tips because it's not nice to just throw a bunch of libraries at an embedded device just to abstract, nor is it easy to make one that's general purpose, so what you wind up with are spells, or if you must "recipes" more than anything: "Here's the general idea, tweak it to taste and effect" and there you go.
And the trick I think, with getting good at these, is getting a bunch of these spells/recipes together, and also getting good at creating them.
Spells and recipes make for garbage coding articles but great cooking articles - see hansel and gretel of the brothers grimm. They really do. They're more art than technical skill. I love them for that, but teaching magic to other people can be tricky. And cooking wayward children is NSFW.
So I'm not really sure where to go with a lot of these. I can't provide readers with nifty drop in coding gadgets, it's all cut to fit. And by that I mean you better know how to use a multi-meter as well as get by without a debugger just for the basics.
I don't know. I feel like the ones I write tend to leave the reader with less than I'd like but I have nothing consistent to offer that would satisfy both me and I think, them.
Hmmm.
Real programmers use butterflies
|
|
|
|
|
Have you thought of blogging? It might be a more appropriate form than technical articles.
Mircea
|
|
|
|
|
I don't really have an existing platform, and am frankly, not looking to manage my own readership, if that makes sense.
Real programmers use butterflies
|
|
|
|
|
There's programming; and there's electronics. (Soldering!?)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
