#1November 27th, 2008 · 05:54 AM
371 threads / 187 songs
3,394 posts
United Kingdom
Mp3 bps
I've noticed on some playbacks that the bps are higher than on others.

I currently convert at 128 bps, which is the preset

What is the best rate to use and can it still be uploaded onto BandAMP?

Cheers

Denis
#2November 27th, 2008 · 09:11 AM
189 threads / 27 songs
2,834 posts
Germany
Guess 128 is ok... I personally prefer 192 and in the case of collaboration I convert to 256. The size of the file is larger but the qualitiy is better
We've heard that some songs with bitrates lower than 128 or off the standard were pitched in frequency and speed and couldnt be reconverted into a hearable sound
but this is not an issue of Bandamp but has to do with that player plugin BandAmp uses.
#3November 27th, 2008 · 10:24 AM
55 threads / 30 songs
1,558 posts
United Kingdom
I think my standard bitrate is set to 160 bps - that said, the internet "standard" is 128 bps and realistically for listening to music in general I guess it's fine.

Interesting what TK says about using 256 for collaboration; if I'm not using WAV files to swap between the collaborators then I use MP3 files of 320 bps!
#4November 27th, 2008 · 12:18 PM
189 threads / 27 songs
2,834 posts
Germany
yep Jim why not... the song "Saviour My Heart" (JBP) and "Anyday" (TritonKeyboarder) were transferred with 256.... This is def not a CD standard. But the goal was to collaborate in an easy way. Personally I prefer the WAV format if MP3 is not wanted
#5November 27th, 2008 · 02:20 PM
371 threads / 187 songs
3,394 posts
United Kingdom
TritonKeyboarder wrote…
yep Jim why not... the song "Saviour My Heart" (JBP) and "Anyday" (TritonKeyboarder) were transferred with 256.... This is def not a CD standard. But the goal was to collaborate in an easy way. Personally I prefer the WAV format if MP3 is not wanted

I'm a little confused, if running at a faster bps gives better quality, my software will do upto 320bps, why not upload all our songs at that rate. I understand it will take longer.

Cheers

Denis
#6November 28th, 2008 · 03:12 AM
189 threads / 27 songs
2,834 posts
Germany
that's quite right, Denis.

Some theoretical thoughts about it:
A normal 3 minute MP3 file with 128 coding has a size of about 3MB. The size of a 320 is much bigger let's say 8-9MB. For users with broadband internet connection there will be no problem to listen to those files in realtime. And the server's site must have a broadband connection too... In the moment I don't know where the developement and the hosting of the website runs.
As a database and site admin I would say upload files as small as possible 128 and 192 should do their job, on the other hand as a musician I want my music be heard with the most possible qualitiy and that's 320 in common mp3 software products. There are other coding standards as well.
If every song is coded to 320 your realtime listening will be interrupted from time to time. That's no fun to listen. I saw this issue on youtube where some downloads are reloaded every few seconds.. To me this is really annyoing. This happens 2-3 times to me and then I stop listening to move to the next thing. The more downloads at the same time the more interrupts will come up.

So that's a little theoretical thought. Let's see what happens when the community and the quality grows.

The next question is why compression to any standard and why not upload WAV files to reach the highest level in quality? which bit format? 16-20-24-28-32 ???? ok it will take longer for uploads but this would really be the dream of a musician to publish his/her work via internet. That's a CD or DVD standard.
again some maths: 3 minutes 16-bit 44100kHz approx 30MB. Studio standard is min. 24-bit.

OMG what traffic on the cable!!!
TLS includes a new media type "video". The same thoughts are valid for this type of media.

Suggestion:
Downstream and listen via player with internet standard MP3 (192, 256 bps, or whatever you prefer to do)
Possible download as WAV?
The user should decide.

Just a thought
 

Perhaps TLS can approve the next standards for further developments.
#7November 28th, 2008 · 07:17 AM
371 threads / 187 songs
3,394 posts
United Kingdom
TritonKeyboarder wrote…
that's quite right, Denis.

Some theoretical thoughts about it:
A normal 3 minute MP3 file with 128 coding has a size of about 3MB. The size of a 320 is much bigger let's say 8-9MB. For users with broadband internet connection there will be no problem to listen to those files in realtime. And the server's site must have a broadband connection too... In the moment I don't know where the developement and the hosting of the website runs.
As a database and site admin I would say upload files as small as possible 128 and 192 should do their job, on the other hand as a musician I want my music be heard with the most possible qualitiy and that's 320 in common mp3 software products. There are other coding standards as well.
If every song is coded to 320 your realtime listening will be interrupted from time to time. That's no fun to listen. I saw this issue on youtube where some downloads are reloaded every few seconds.. To me this is really annyoing. This happens 2-3 times to me and then I stop listening to move to the next thing. The more downloads at the same time the more interrupts will come up.

So that's a little theoretical thought. Let's see what happens when the community and the quality grows.

The next question is why compression to any standard and why not upload WAV files to reach the highest level in quality? which bit format? 16-20-24-28-32 ???? ok it will take longer for uploads but this would really be the dream of a musician to publish his/her work via internet. That's a CD or DVD standard.
again some maths: 3 minutes 16-bit 44100kHz approx 30MB. Studio standard is min. 24-bit.

OMG what traffic on the cable!!!
TLS includes a new media type "video". The same thoughts are valid for this type of media.

Suggestion:
Downstream and listen via player with internet standard MP3 (192, 256 bps, or whatever you prefer to do)
Possible download as WAV?
The user should decide.

Just a thought
 

Perhaps TLS can approve the next standards for further developments.

Thanks TK, this is most imformative

Denis
#8December 2nd, 2008 · 01:12 PM
117 threads / 20 songs
1,422 posts
United States of America
Yeah, it's really just a question of quality preference when it comes to BandAMP.  When I work on incomplete projects, I don't compress it at all in between working sessions.  I leave it in WAV format, which is huge, but lossless when it comes to quality.

When I finally export as an mp3, I tend to go 192kbps.  128 is kind of the internet standard, but I constantly find little audio quality issues at 128.  they're often just minor, but they are there nonetheless.  I rarely hear anything wrong at 192, and certainly 320 would be almost as perfect as you can get.  Some other formats allow for bit-rates in the 400's as well.  they're not nearly as common as the mp3 format, though.  (I'm thinking of "ogg" format, I believe.)

Anyway, the only way that this can affect people on bandamp is that supposedly there's an 8mb limit in filesize.  When I uploaded my piano song (The End of Tribulation), it was too long for me to encode at 192 and stay under 8mb, so I had to go 128, I believe.

Be aware that there is also a variant of this bit-rate nonsense, called "VBR" (Variable Bit Rate).  All that means is that you can pick a target bitrate, like 128 or 192 or 160 or 320, and then the software will compress your audio at *approximately* the value you chose.  If it doesn't need to be 128 at a certain point in the song, it will drop down to a lower bitrate.  If parts of the song need to be at a higher bitrate to capture the quality of the sound better (lots of sounds happening at the same time, or maybe just really deep sounds and really high ones at the same time), then it'll go above the limit you specified.  In the end, you have a more efficiently encoded mp3, because the spots that didn't need full-out encoding at 192 won't get it, but parts that needed 256 will get it.

Anyway.  Sometimes VBR-encoded songs have their length messed up in the player we use.  That's because mp3 song lengths (in terms of minutes and seconds) are calculated by how much data is in the song at the sampling rate you've chosen.  It gets hard for the player to calculate that when the bitrate is changing throughout the song.

So.  That's an end to my bit of theory as well
#9December 2nd, 2008 · 02:47 PM
371 threads / 187 songs
3,394 posts
United Kingdom
TonightsLastSong wrote…
Yeah, it's really just a question of quality preference when it comes to BandAMP.  When I work on incomplete projects, I don't compress it at all in between working sessions.  I leave it in WAV format, which is huge, but lossless when it comes to quality.

When I finally export as an mp3, I tend to go 192kbps.  128 is kind of the internet standard, but I constantly find little audio quality issues at 128.  they're often just minor, but they are there nonetheless.  I rarely hear anything wrong at 192, and certainly 320 would be almost as perfect as you can get.  Some other formats allow for bit-rates in the 400's as well.  they're not nearly as common as the mp3 format, though.  (I'm thinking of "ogg" format, I believe.)

Anyway, the only way that this can affect people on bandamp is that supposedly there's an 8mb limit in filesize.  When I uploaded my piano song (The End of Tribulation), it was too long for me to encode at 192 and stay under 8mb, so I had to go 128, I believe.

Be aware that there is also a variant of this bit-rate nonsense, called "VBR" (Variable Bit Rate).  All that means is that you can pick a target bitrate, like 128 or 192 or 160 or 320, and then the software will compress your audio at *approximately* the value you chose.  If it doesn't need to be 128 at a certain point in the song, it will drop down to a lower bitrate.  If parts of the song need to be at a higher bitrate to capture the quality of the sound better (lots of sounds happening at the same time, or maybe just really deep sounds and really high ones at the same time), then it'll go above the limit you specified.  In the end, you have a more efficiently encoded mp3, because the spots that didn't need full-out encoding at 192 won't get it, but parts that needed 256 will get it.

Anyway.  Sometimes VBR-encoded songs have their length messed up in the player we use.  That's because mp3 song lengths (in terms of minutes and seconds) are calculated by how much data is in the song at the sampling rate you've chosen.  It gets hard for the player to calculate that when the bitrate is changing throughout the song.

So.  That's an end to my bit of theory as well :D

Oh wow TLS you really seem to know your stuff. I've just uploaded a new song called 'Wishing Well', which is at 192 birate, Seems better to me than what I usually use at 128.

Interesting what you said about capturing the higher and lower notes, I'll try a birate of 256 next time depending on the lenght of the song.

Thanks a lot for this.

Cheers

Denis
#10December 2nd, 2008 · 03:13 PM
117 threads / 20 songs
1,422 posts
United States of America
The default compression for mp3 will try to cut high tones from music first.  I remember encoding into an mp3 a crazy metal-ish song from the old DOS game "Descent".  At one point it had this insanely high whirling guitar part, but it was completely vanished from the song when I encoded at anything below 256kbps.  It was rather eerie how cleanly the compression got rid of that guitar part.

Some encoders will try to raise the volume of those parts so that they will match what the rest of the audio is being encoded in.  The basic mp3 encoder that most programs use ("LAMEenc.dll") won't get that fancy though, so you'd be better off trying to find that sweet spot for bit-rate, where you don't lose anything from your sound.

Often the sounds to get sacrificed by poor bit-rate are very low tones and very high tones.  They kind of distort, as if there was clipping going on.
Sorry, you do not have access to post...
Wanna post? Join Today!

Server Time: April 19th, 2024 · 7:19 PM
© 2002-2012 BandAMP. All Rights Reserved.