PDA

View Full Version : VBR vs CBR for mp3s on SB



smc2911
2006-03-13, 00:12
Like some others on the forums, I've had stuttering issues playing my ogg and flac files over the wireless network, but no problems with my mp3s. Since I have flac copies of my entire collection and no shortage of disk space, I've decided to fire up foobar2000 to batch produce mp3 copies of everything. I'm curious to know whether I should use VBR or CBR. My current mp3s (which are quite old) are mostly CBR, but I'm more inclined to go with VBR. Am I correct in assuming that SB will handle VBR natively and avoid the problems I am currently experiencing with ogg?

Sean.

snarlydwarf
2006-03-13, 00:17
Most of my mp3's are 240kbps vbr. I can't hear the difference between them and flac on most material.

If network bandwidth/reliability is a problem, yes, that should ease up the bandwidth needed substantially and allow more network hiccups to hide in the sb buffer.

smc2911
2006-03-13, 03:41
So, if I use a lower quality would I be better off using a constant bit-rate (say 192kps) or variable, say --preset standard (corresponds to approx 170-210kbs). Normally I'd choose the variable, but was wondering whether constant bit rate resulted in better SB performance. I did a batch run on --preset extreme and the performance was much better than the oggs/flacs, but some tracks did sit on 0% bugger and show the occasional stutter, so maybe I need to drop a bit lower.

Note, I've been using 192kps bitrate limiting, but assume that this will only affect playback of ogg and lame, not mp3s which are handled natively.

Sean.

snarlydwarf
2006-03-13, 08:51
VBR sounds better than CBR. The reason is that it allows some slop for complex sections: it can switch to a higher bitrate for a few frames of complex stuff.

Unless you have a device (some early mp3 portables for example) that gets confused by vbr, it's much much better. (some players used to go nuts with 'time remaining' on vbr files.. they figured the time simply by multiplying the frame count by the bit rate.)

Robin Bowes
2006-03-13, 09:13
snarlydwarf wrote:
> VBR sounds better than CBR.

Certainly does.

I'm currently listening to a random mix - mostly FLAC, with a few MP3.
An mp3 @ 160CBR just came on and it sounds poor compared to the 192VBR
files and completely flat compared to the FLACs!

R.

radish
2006-03-13, 10:35
Why don't you just configure Slimserver to transcode ogg & flac to mp3? That saves a (long) processing step and a lot of disk space.

Robster
2006-03-13, 10:59
[QUOTE=Robin Bowes]snarlydwarf wrote:
> VBR sounds better than CBR.

Certainly does.

I'm currently listening to a random mix - mostly FLAC, with a few MP3.
An mp3 @ 160CBR just came on and it sounds poor compared to the 192VBR
files and completely flat compared to the FLACs!


Okay I get that but does 320cbr sound better than 320vbr or about the same?

Rob

JJZolx
2006-03-13, 11:08
So, if I use a lower quality would I be better off using a constant bit-rate (say 192kps) or variable, say --preset standard (corresponds to approx 170-210kbs). Normally I'd choose the variable, but was wondering whether constant bit rate resulted in better SB performance. I did a batch run on --preset extreme and the performance was much better than the oggs/flacs, but some tracks did sit on 0% bugger and show the occasional stutter, so maybe I need to drop a bit lower.
For a given file size, VBR should sound better than CBR.


Note, I've been using 192kps bitrate limiting, but assume that this will only affect playback of ogg and lame, not mp3s which are handled natively.
If you're using bitrate limiting, I don't believe that assumption is true. I believe (someone correct me if I'm wrong) that if you set bitrate limiting, then mp3s are also be transcoded to the target bitrate. The only way the files would be streamed in their original form would be to disable bitrate limiting.

Note that SlimServer uses ABR (average bitrate rate), which is a type of variable bitrate, but is intended to keep the encoding rate (and thus the streaming rate) at a more controlled rate that is possible with VBR. If there are any mp3s that are _not_ transcoded by SlimServer, I would think it could only be CBR encoded files at bitrates at or below the set limit. I'm not sure whether SlimServer does this, though - it may just transcode everything.

Robin Bowes
2006-03-13, 11:26
Robster wrote:
> Robin Bowes Wrote:
>
>>snarlydwarf wrote:
>>
>>>VBR sounds better than CBR.
>>
>>Certainly does.
>>
>>I'm currently listening to a random mix - mostly FLAC, with a few MP3.
>>An mp3 @ 160CBR just came on and it sounds poor compared to the 192VBR
>>files and completely flat compared to the FLACs!
>>
>
>Okay I get that but does 320cbr sound better than 320vbr or about the
>same?
>

Well, at that bit rate, I would say that they'll probably sound similar.
Theoretically the vbr *should* be better.

I'm guessing though as I use predominantly flac.

R.

kdf
2006-03-13, 11:29
Quoting JJZolx <JJZolx.24me6n1142273401 (AT) no-mx (DOT) forums.slimdevices.com>:

> If you're using bitrate limiting, I don't believe that assumption is
> true. I believe (someone correct me if I'm wrong) that if you set
> bitrate limiting, then mp3s are also be transcoded to the target
> bitrate.

only if the native bitrate is found to be higher. If you limit at
192, then 128kbps mp3 and even 192 kbps files should play natively.
-k

Robster
2006-03-13, 11:49
Well, at that bit rate, I would say that they'll probably sound similar.
Theoretically the vbr *should* be better.


I can't see why it would, surely everything at 320kps would sound better than some parts at less?

JJZolx
2006-03-13, 11:49
Quoting JJZolx <JJZolx.24me6n1142273401 (AT) no-mx (DOT) forums.slimdevices.com>:

> If you're using bitrate limiting, I don't believe that assumption is
> true. I believe (someone correct me if I'm wrong) that if you set
> bitrate limiting, then mp3s are also be transcoded to the target
> bitrate.

only if the native bitrate is found to be higher. If you limit at
192, then 128kbps mp3 and even 192 kbps files should play natively.
Is that also true for VBR and ABR encoded files? Does the 'target' bitrate get recorded in the metadata for those files?

kdf
2006-03-13, 12:11
Quoting JJZolx <JJZolx.24mg1b1142275802 (AT) no-mx (DOT) forums.slimdevices.com>:


>> only if the native bitrate is found to be higher. If you limit at
>> 192, then 128kbps mp3 and even 192 kbps files should play natively.
> Is that also true for VBR and ABR encoded files? Does the 'target'
> bitrate get recorded in the metadata for those files?
>
I'm not sure what method is used, but there is a bitrate value in the
db. That is used. I was doing some experiments with moodlogic,
musicmagic and slimserver imports. They all had slightly different
values for the bitrate of a non-cbr file. Given that, I assume there
must be some calculation done, but I haven't gone digging into the
CPAN module to get specifics.

Whatever the slimserver db has for the bitrate, is what will be used
to determine if bitrate limiting is required. It is based on number
only, and any variable bursts should be handled by proper buffer
configuration by the user for the given client software.
-k

pablolie
2006-03-13, 12:15
I am very satisfied with 320kbps CBR MP3s, but it's truly only worth it for recordings of very good quality, and wasted on most, which are totally happy with 256k CBR MP3. I never store anything with less than 256k. Only for my portable msuic devices do I compress more, and typically use the Windows media format at 128k, which is more than good enough for that purpose.

Robin Bowes
2006-03-13, 13:02
Robster wrote:
> Robin Bowes wrote:
>> Well, at that bit rate, I would say that they'll probably sound
>> similar.
>> Theoretically the vbr *should* be better.
>
>
> I can't see why it would, surely everything at 320kps would sound
> better than some parts at less?

Why would that be the case?

VBR uses an average bit rate, i.e. it reduces the bit rate where it can
to reduce file size. If the track is complex it won't reduce the bit
rate, i.e. it will be 320kbs or higher.

R.

smc2911
2006-03-16, 18:57
Thanks for all the feedback. Having experimented a bit more, I'll share my experiences which should help explain my thinking in asking the question in the first instance.

I am using a wireless connection for my SB with the router upstairs and the SB downstairs. Moving the router around the room, sniffing with NetStumbler to make sure I'm using a channel clear of neighbourly networks, I think I've got my reception as good as it's going to get without investing in new equipment. I typically register a signal strength of around 70% on the SB. I also tried the NetTest plugin and only ever showed less than 100% performance when I pushed the bit rate past 2000kbps.

I have two cuts of my music collection. One built up over a long period of time and so is a bit of a hodge-podge: mp3s (some 128kbps, mostly 192kbs, some 256kbs), oggs and a few flacs. The second is all flac (this is a work in progress, but about 80% of thw way through the collection now). I also have plenty of spare disc space.

Streaming the original collection, I had no problems with the mp3s but the oggs and flacs didn't really work at all (stuttery nonsense). I then realised that the server couldn't find LAME, so I fixed that and set bitrate limiting to 256. Now the oggs and flacs would start playing ok, but then get a bit stuttery (all the while the buffer read 0%, while for the mp3s it would show 20-50%). Some would get get very bad and hang the SB: no response from the remote or stopping playback through the web-browser, I'd have to unplug. I then pushed the bitrate down to 192kbs and the problem continued. Since my 192kps mp3s were fine, I thought that wireless bandwidth couldn't be the problem, maybe the CPU on the server was overloaded, but trying from both a WinXP box and a Linux box, I could see slimserver and LAME both running but using less than 5% CPU combined. I thought that maybe the slimserver and/or LAME thread needed to have it's priority increased, but wasn't sure how to do this.

Edit:
Maybe I should have read http://www.slimdevices.com/su_faq.html more carefully!

I'm using the SlimServer as a Windows service but the performance isn't good. The music sometimes is choppy and the menus aren't very responsive, especially when it's scanning my music library. What can I do?

By default, Windows doesn't give high priority to services and the SlimServer software sometimes needs a fair amount of CPU. To work around this, open your "Control Panels", and then open the "System" control panel. On the "Advanced" tab, find the "Performance" section and click on "Settings". On the "Advanced" tab, choose "Backround Services" under "Processor Scheduling". Click "OK" and the SlimServer software will now get more CPU cycles and perform better.

So, much as I like ogg for lossy (they sound great on my iRiver), I felt thwarted so I thought I'd use foobar2000 to create mp3s on some spare disc space from my flacs. This took about 36hours (for around 350 albums), but that was ok. For some reason I chose VBR using the LAME --preset extreme setting. After I kicked the batch process off, I posted the original comment in this thread, and then (following some responses) I realised that the VBR would might have the same problem as the ogg since it would sometimes be bitrate limited. Oh, well. Upon completion, I found that almost all tracks have been working fine with bitrate limiting set to 256kps, but one or two got a little jittery. Knocking down to 192kbs sorted these ones out. In particular, VBR mp3s would play when an ogg of the same track would not.

Next I'm going to get a little more scientific: I'll pick a known problem ogg track and try flac, ogg, and a few mp3s (VBR and CBR) all at various bitrate limiting settings and post the results.

Any performance tweaking tips in the meantime would be appreciated!

Sean.

smc2911
2006-03-17, 17:55
I had been experiencing the above problems on both a WinXP and Linux machine, both of which were running 6.2.1. I then tried 6.5 (using the debian package http://wiki.slimdevices.com/index.cgi?DebianPackage) and now it screams along! I can play all of the mp3s with no bit-rate limiting and the buffer sits at 100% the whole time. The flacs also work without stuttering. There's still something to sort out with oggs (I think I need a newer version of sox). Since overnight there was also a new firmware update for the SB, it occurred to me that that might have improved things, but the WinXP server which is still running 6.2.1 still has the old problems.

Sean.