Finally, after all these years!
-
I have no idea what that means. As far as I understood, 320kbps is near-lossless audio quality, as opposed to 192 or even 128. Of course I could go FLAC, but that's way too much MBs per minute.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I ripped all mine to 128, I tried 320 but I couldn't tell the difference except for having way bigger files. I also temporarily put them on a USB stick to play in the car - usually at 64kbps because the sound quality is basically the same when you are driving around I can get hundreds of tracks on an 8GB stick. PS. I use Mp3Tag for all the tagging and/or renaming. it works very well and saved me from writing my own.
- I would love to change the world, but they won’t give me the source code.
-
I ripped all mine to 128, I tried 320 but I couldn't tell the difference except for having way bigger files. I also temporarily put them on a USB stick to play in the car - usually at 64kbps because the sound quality is basically the same when you are driving around I can get hundreds of tracks on an 8GB stick. PS. I use Mp3Tag for all the tagging and/or renaming. it works very well and saved me from writing my own.
- I would love to change the world, but they won’t give me the source code.
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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
And miss out on this achievement? Nah :D However, now I could take a look at filebot (I just needed to write it, not actually use it) :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
You have completed this journey. No more need be explained.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I have no idea what that means. As far as I understood, 320kbps is near-lossless audio quality, as opposed to 192 or even 128. Of course I could go FLAC, but that's way too much MBs per minute.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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
-
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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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.
-
Almost as if you haven't heard about Mp3tag - the universal Tag Editor (ID3v2, MP4, OGG, FLAC, ...)[^]
Wrong is evil and must be defeated. - Jeff Ello Never stop dreaming - Freddie Kruger
MP3Tag is AWESOME! I wish it could do a certain routine for all subfolders in a folder, like: grab tags from Discogs, rename files to a certain pattern, save the m3u playlist, and move on to the next subfolder. All things it does very well, but only manually.
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
leSSov vIleghbogh suvwI' tIlegh. I don't think it translates back to English :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
I don't think it translates back to nice English
FTFY ;) ;P
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Quote:
ripping my considerable CD collection into 320kbps MP3's
Aren't your CD's recorded at 44.1k? What will you achieve by upsampling?
Mircea
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.
-
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
:confused: 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
-
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
-
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! :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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
I wasn't going to say that in so much detail, but yes, kbps and sampling rate are different things :laugh: I don't really know what those values mean, but 320 kbps == good quality. I'm not touching any sample rates, although I do have a program that let's me set it, as well as kbps.
Mircea Neacsu wrote:
That should teach me not to post before researching :(
You are hereby forgiven ;p
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
You have completed this journey. No more need be explained.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
I think you might be the only one who got the essence of my message :omg:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
In any case, I wanted to roll out my own because that's what real programmers do :cool:
To quote @CPallini... Real Programmers are Klingon Programmers
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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
Mircea Neacsu wrote:
That should teach me not to post before researching
Don't worry... that is true for maaaaaaaaaaany people here and in the internet (me included... I have had my :doh: :doh: :doh: :doh: :doh: moments too :-O :laugh: :laugh: )
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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
-
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? T
-
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
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.
-
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.
Yes, I realized my mistake and apologized for it [^]. I can only say sorry again :(
Mircea
-
I wasn't going to say that in so much detail, but yes, kbps and sampling rate are different things :laugh: I don't really know what those values mean, but 320 kbps == good quality. I'm not touching any sample rates, although I do have a program that let's me set it, as well as kbps.
Mircea Neacsu wrote:
That should teach me not to post before researching :(
You are hereby forgiven ;p
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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.)
