Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Lossless to 128 vs. 320 to 128 - Any difference? (Read 10613 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lossless to 128 vs. 320 to 128 - Any difference?

Hello all,

I'm developing a small website where you have to guess the bitrate of a sound sample. Kind of like an ABX test, but a lot more informal.
Most of the code is ready so I'm gathering a sound library of varying genre's, but it's proving difficult to find all the files in lossless format. I need them as a template to encode into different bitrates - 320, 192, 128 and 96. Some online music stores offer the option of getting it in FLAC or WAV, but not all of the songs I want to use are available. I really can't be bothered buying entire albums just to rip one song off of them.

My question is: can I get away with using a 320kbps as a template file or will there be too great of an audible difference? I've tested this out by reencoding an 320kbps mp3 and its FLAC source file into varying bitrates, but I can't tell a difference. Neither do I see much on a spectrogram. I gotta be honest though, my ears aren't as accurate as I'd like them to be - I sometimes have trouble discerning the difference between 320 and 192.

Can anyone shed any light on this problem? Any help would be greatly appreciated!

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #1
Most of the time most people will not be able to tell the difference with most material. That's a pretty vague answer, I know, but it's hard to be any more specific.

Could you provide more details of what you have planned and what you expect to get out of it?

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #2
The website is just a simple project for fun. You have to sort a few audio files in order of sound quality.

I was hoping that maybe someone with deeper knowledge of the mp3 codec could explain what reencoding a 320 to a lower bitrate does (specifically LAME). Maybe the data loss of the 320kbps file compounds together with the data loss of reconverting it to 192kbps to something more drastic. Maybe the codec detects that the previous file has already been encoded to mp3 before and thus modifies its parameters to accompany that. Maybe the sound quality of the previous file has no direct influence if the bitrate is high enough. I don't know.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #3
Some online music stores offer the option of getting it in FLAC or WAV, but not all of the songs I want to use are available. I really can't be bothered buying entire albums just to rip one song off of them.
  ...
My question is: can I get away with using a 320kbps as a template file or will there be too great of an audible difference?


If you can't be bothered buying a CD and ripping, then why not just use a different song that is available lossless?

IMO if this is for people to test what they can hear, you owe them the real deal.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #4
"Sorting in order of sound quality" may not give you the results you expect. When encoding artifacts change the way something sounds, that does not necessarily means that it sounds "worse" to everyone who can hear a difference. It would be more meaningful if the test subjects were determining which sounds closest to the original.

This is not meant to support claims that a certain age group has listened to lossy encoded music most of their lives and now prefers that over lossless. 

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #5
If you can't be bothered buying a CD and ripping, then why not just use a different song that is available lossless?

IMO if this is for people to test what they can hear, you owe them the real deal.


I want the sound samples to come from a broad musical spectrum to try and appeal to many people's musical tastes. And it has to be well produced as well - I don't want to just feature any song. So unless I can find a compilation album that has a lot of them put together, I'll have to resort to buying an album for every single song. Since I'd like to put at least 30 songs on there, that will amount to a huge price where the majority of the music isn't something I need anyway. I don't think it's unreasonable to not want to do that.

Plus, a lot of the songs aren't even available on an album. For many, 320kbps is the only option.

Edit: It might be useful to add that this won't be a listening test for FLAC/ALAC vs. mp3. Browsers can't decode those anyway. Only mp3s will be used.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #6
I was hoping that maybe someone with deeper knowledge of the mp3 codec could explain what reencoding a 320 to a lower bitrate does (specifically LAME). Maybe the data loss of the 320kbps file compounds together with the data loss of reconverting it to 192kbps to something more drastic.
Yes, this is perfectly possible. Transcoding from a lossy source, even at a high bitrate, might produce new lossy files of audibly worse quality than if they had been properly encoded from the uncompressed/lossless original. This is one of the main reasons we advise against transcoding.

Quote
Maybe the codec detects that the previous file has already been encoded to mp3 before and thus modifies its parameters to accompany that.
No, not one bit. This assumption has been debunked many times in previous discussions along similar lines.

Quote
Maybe the sound quality of the previous file has no direct influence if the bitrate is high enough. I don't know.
As above, this cannot be guaranteed and should not be assumed.

Will an audible difference arise because of the lossy nature of the template? Who knows? But the mere possibility largely invalidates the methodology, if you ask me. I would not be able to put much or any trust in conclusions from such a test as being informative about those various settings in scenarios where they were used properly.

You might object that although the average quality will be reduced across the set, the same phenomenon of lower quality as the bitrate decreases will be preserved. Maybe, yes. But again, the whole idea is suboptimal.

Do we think that, given the possibility that lossless sources may not be available, transcoding and hoping the broad strokes stay the same would be an acceptable compromise?

It might be useful to add that this won't be a listening test for FLAC/ALAC vs. mp3. Browsers can't decode those anyway. Only mp3s will be used.
Speaking of broad strokes, this is false. Some browsers can decode such formats perfectly well: it depends upon the browser in question and perhaps the presence of appropriate plugin(s). Please do not overgeneralise like this.

 

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #7
db1989 addressed your other statements, so:
I want the sound samples to come from a broad musical spectrum to try and appeal to many people's musical tastes. And it has to be well produced as well - I don't want to just feature any song.

There are many free and openly-licensed recordings of music online that you could use for this test.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #8
Yes, this is perfectly possible. Transcoding from a lossy source, even at a high bitrate, might produce new lossy files of audibly worse quality than if they had been properly encoded from the uncompressed/lossless original. This is one of the main reasons we advise against transcoding.

Ah thanks, that was the information I was looking for. I'm going to select more available songs then.

I went looking into the website of LAME, and I found something interesting. There is a command line option when encoding, '--mp3input', that enables you to use a lossy file as input. To quote them:
Quote
Assume the input file is a MP3 file.  LAME will decode the input file before re-encoding it.  Since MP3 is a lossy format, this is not recommended in general.  But it is useful for creating low bitrate mp3s from high bitrate mp3s.  If the filename ends in ".mp3" LAME will assume it is an MP3.  For stdin or MP3 files which dont end in .mp3 you need to use this switch.

So it isn't recommended, but they still have the option for re-encoding it to a lower bitrate. Unfortunately there isn't much more information on the quality of the transcoding, but I'll play it safe and assume the worst.

Quote
Speaking of broad strokes, this is false. Some browsers can decode such formats perfectly well: it depends upon the browser in question and perhaps the presence of appropriate plugin(s). Please do not overgeneralise like this.

Of course it's possible, but when developing a website you aim for compatibility with all the major browsers/systems. It's just impractical to have your website depend on a plugin. I meant no harm with that statement...

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #9
Edit: It might be useful to add that this won't be a listening test for FLAC/ALAC vs. mp3. Browsers can't decode those anyway. Only mp3s will be used.

Most of the browsers supports PCM audio in the WAV container. You can use that for the lossless reference. I guess you'll not provide full length songs anyway because then you have to deal with copyright issues. So the size difference between FLAC/ALAC and WAV doesn't really matter in this case.
I would even decode MP3's back to WAV and use those with meaningless filenames so people with a developer console can't identify the different tracks so easily. This way you can even introduce other codecs later on because you don't have to rely on the browser support.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #10
I went looking into the website of LAME, and I found something interesting. There is a command line option when encoding, '--mp3input', that enables you to use a lossy file as input. To quote them:
Quote
Assume the input file is a MP3 file.  LAME will decode the input file before re-encoding it.  Since MP3 is a lossy format, this is not recommended in general.  But it is useful for creating low bitrate mp3s from high bitrate mp3s.  If the filename ends in ".mp3" LAME will assume it is an MP3.  For stdin or MP3 files which dont end in .mp3 you need to use this switch.

So it isn't recommended, but they still have the option for re-encoding it to a lower bitrate. Unfortunately there isn't much more information on the quality of the transcoding, but I'll play it safe and assume the worst.

But it says right there that (A) all this option does is to force LAME to treat the input file/stream as MP3 if it is not indicated as such in its filename, and (B) all that will happen, in any case, is that LAME will decode the incoming MP3 to WAV and then re-encode that uncompressed stream.

Exactly the same as would happen in every other possible method of conversion, regardless of which program(s) you use as the front-end. There is precisely no facility, anywhere, for converting one MP3 directly to another without intermediate decoding and re-encoding. And this holds for all compressed formats, save for a few brief and unfruitful excursions into concepts such as bitrate peeling and some recent developments in MPEG-4 SLS, which is still a very niche product.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #11
There are many free and openly-licensed recordings of music online that you could use for this test.

Great, that would be perfect! Can you tell me where I can find them?

Most of the browsers supports PCM audio in the WAV container. You can use that for the lossless reference. I guess you'll not provide full length songs anyway because then you have to deal with copyright issues. So the size difference between FLAC/ALAC and WAV doesn't really matter in this case.
I would even decode MP3's back to WAV and use those with meaningless filenames so people with a developer console can't identify the different tracks so easily. This way you can even introduce other codecs later on because you don't have to rely on the browser support.

The biggest issue with that is not even the copyrights, it's the file size. Just a 5 second segment of pure PCM can be a full megabyte. In a web development perspective, that's huge! And to upload multiple files would just make it impossible. Both in terms of server cost and client download speed.

But it says right there that (A) all this option does is to force LAME to treat the input file/stream as MP3 if it is not indicated as such in its filename, and (B) all that will happen, in any case, is that LAME will decode the incoming MP3 to WAV and then re-encode that uncompressed stream.

Exactly the same as would happen in every other possible method of conversion, regardless of which program(s) you use as the front-end. There is precisely no facility, anywhere, for converting one MP3 directly to another without intermediate decoding and re-encoding. And this holds for all compressed formats, save for a few brief and unfruitful excursions into concepts such as bitrate peeling and some recent developments in MPEG-4 SLS, which is still a very niche product.

Yeah, I agree. The website mentions it uses mpglib/mpg123 to decode it back to PCM. What's your point? Nothing you've said contradicts anything I've said.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #12
As long as you limit the samples to less than 30 seconds, you should not need to worry about copyrights.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #13
There are many free and openly-licensed recordings of music online that you could use for this test.

Great, that would be perfect! Can you tell me where I can find them?

http://www.lmgtfy.com/?q=free+open+music

What's your point? Nothing you've said contradicts anything I've said.

To quote you:
Quote
I went looking into the website of LAME, and I found something interesting. There is a command line option when encoding, '--mp3input', that enables you to use a lossy file as input.

This is not interesting or special.  LAME can decode an mp3 to wav, allowing you to reencode.
Quote
Unfortunately there isn't much more information on the quality of the transcoding, but I'll play it safe and assume the worst.

LAME will encode valid input with whatever parameters you include.  There is no special mp3 to mp3 transcoding feature in the program.  That is what db1989 said.

If you want to find out more about the transcoding quality, you could set up a listening test for transcoded mp3 audio.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #14
There are many free and openly-licensed recordings of music online that you could use for this test.

Great, that would be perfect! Can you tell me where I can find them?

http://www.lmgtfy.com/?q=free+open+music

Did you actually go through those sites? None of those sites are lossless, which was the whole point of this thread. Thanks for being helpful though.

I did find a few sites that have .wav files, but they tend to be either just sound effects, or badly recorded music. I'll keep digging.

Lossless to 128 vs. 320 to 128 - Any difference?

Reply #15
archive.org could be a good starting point. Although I just glanced at it, I already found its archive of live music, and if you want studio-based stuff, that might be available in other categories.

And testyou realised what I meant. Maybe my post was a bit redundant, but I made it just in case you thought the option in LAME would be any different from any other converting workflow.