PDA

View Full Version : Sound Quality w/ Latest Firmware



jhwilliams
2005-10-21, 16:29
I have been trying out the new SlimServer 6.2 beta. I noticed that the sound wasn't as sharp when I used 6.2 against 6.1 - I did a blind test with my girlfriend and she picked the difference every single time.

After a bit of experimentation it turns out the actual factor was the firmware - if I use the same firmware from 6.1 the sound is noticably better.

Additionally, I seem to be having the opposite issue to many on here - with the newer firmware the SB2 isn't loud enough to drive my amp. Even with the preamp setting at zero it is quieter than the 6.1 firmware.

I've tried all the various player audio settings (different gain settings, etc). But the result is consistently the same - flatter sound at lower volumes.

Anyone got any advice? Is there a set of settings which I should be trying out?

ps. My setup is SB2 wireless, direct to amp. Test files all FLAC ripped w/ EAC.

I think the actual firmware versions involved was 15 for 6.1 and 40 for 6.2 (?).

seanadams
2005-10-21, 16:35
I've tried all the various player audio settings (different gain settings, etc). But the result is consistently the same - flatter sound at lower volumes.


The volume curve has changed.

jhwilliams
2005-10-21, 16:57
The volume curve has changed.

Is that to make it more linear?

I still find that with preamp at zero, max volume isn't as loud as it used to be (I realise this is the opposite issue to everyone else in here).

Any ideas/suggestions regarding the flatness of the sound? I have tried a bunch of different setting combinations - or perhaps another question - what settings will give audio behaviour similar/same as the old firmware?

seanadams
2005-10-21, 17:03
Is that to make it more linear?

I still find that with preamp at zero, max volume isn't as loud as it used to be (I realise this is the opposite issue to everyone else in here).


Perhaps replaygain is in effect?



Any ideas/suggestions regarding the flatness of the sound?

Can you be more specific?

jhwilliams
2005-10-21, 20:06
Perhaps replaygain is in effect?


I've disabled replaygain - i haven't bothered to run any tests (my equipment is packed), but i'd guess i can't get around half the range.


Can you be more specific?

Unfortunately I can only be subjective - the sound with the new version seems to roll off. I'm not that great with audiophile terminology, but i find the soundstage with v15 seems much better - especially with classical music.

I have a cd of african music where it is quite apparent - with v15 you feel like they are in the room, with the latest version that positioning is lost/collapsed.

I've got an outboard DAC (not here yet), so it's not a massive issue - just wondering if there are particular configurations that I should be trying.

seanadams
2005-10-21, 22:26
Unfortunately I can only be subjective - the sound with the new version seems to roll off. I'm not that great with audiophile terminology, but i find the soundstage with v15 seems much better - especially with classical music.


We'd have to identify something specific, otherwise it isn't anything I can look into. The most helpful thing by far would be if you could capture a recording from the digital outputs using a good s/pdif sound card, just so we can make sure the data is getting through the same as before. I can't think of anything that would be molesting the data here, and as far as we know everything is still correct in digital land.

WRT to the DAC, the only thing I can think of that has changed would be that we have corrected the polarity (aka phase) of the analog outputs. They were inverted before. If you can hear a difference, that's damn impressive as there is a long standing debate as to whether absolute phase is audible. :)

Patrick Dixon
2005-10-22, 03:04
Can you give us some more info on your setup? You say SB2 direct to amp, but you then talk about a preamp volume setting. What actual volume numbers are you using in each case?

I've found that with an SB2 directly into an amp, whereas I used to listen at around 20-25 on the SB2 volume setting, I'm now listening at 30-35. The 'new' settings give much more control at lower volumes (which I never use!), at the expense of larger steps at high volumes; but since they better match the response of the human ear, overall it's a much better approach.

IIRC, the volume control steps are now about 1.5db, so 35 is probably 'about' the same level as 20 on the 'old' linear system. When doing A/B tests, it quite important to properly match levels or you will find that the slightly louder one is often prefered (even if they are the same otherwise). Some audio systems don't seem to 'come alive' until you reach a certain volume level, so it's just possible that this is what's happening for you.

jhwilliams
2005-10-22, 04:52
We'd have to identify something specific, otherwise it isn't anything I can look into. The most helpful thing by far would be if you could capture a recording from the digital outputs using a good s/pdif sound card, just so we can make sure the data is getting through the same as before. I can't think of anything that would be molesting the data here, and as far as we know everything is still correct in digital land.

I will do - I don't have all my equipment yet, but when I do I'll give it a shot. I also have an outboard dac coming which will help isolate.


WRT to the DAC, the only thing I can think of that has changed would be that we have corrected the polarity (aka phase) of the analog outputs. They were inverted before. If you can hear a difference, that's damn impressive as there is a long standing debate as to whether absolute phase is audible. :)

Interesting! I don't know much about it, but I would have assumed the same re: phase.

That said, it's interesting you mention that and that the CD I find most noticable is of african music (lots of voice, timbre, etc). On the back of that I tried changing the speaker orientation a little and found it helped a lot. Not sure what this all means - I haven't had time to investigate further yet (or try another proper blind test).

Additionally, I have a tube amp, which may be inverting phase itself. So a few things to try... My wiring is a bit of a pain and doesn't lend itself easily to switching back and forth - I might see if I can produce an inverted WAV. Thanks for the tip.

jhwilliams
2005-10-22, 04:58
Can you give us some more info on your setup? You say SB2 direct to amp, but you then talk about a preamp volume setting. What actual volume numbers are you using in each case?

I've found that with an SB2 directly into an amp, whereas I used to listen at around 20-25 on the SB2 volume setting, I'm now listening at 30-35. The 'new' settings give much more control at lower volumes (which I never use!), at the expense of larger steps at high volumes; but since they better match the response of the human ear, overall it's a much better approach.

IIRC, the volume control steps are now about 1.5db, so 35 is probably 'about' the same level as 20 on the 'old' linear system. When doing A/B tests, it quite important to properly match levels or you will find that the slightly louder one is often prefered (even if they are the same otherwise). Some audio systems don't seem to 'come alive' until you reach a certain volume level, so it's just possible that this is what's happening for you.

I've got a McIntosh tube amp - fed directly from the SB2. The amp feeds my speakers directly, so a pretty simple setup for now.

With the old firmware I was running pretty similar values to you - low 20's before and low 30's now.

The preamp setting I referred to is the new preamp value in the player settings (for the latest firmware). I've left this at zero and also turned off the gain correction.

You might be right regarding the volume. Generally in my tests I've tried to get the volume consistent between the two by ear, so you're right that it might be missing a few db without knowing (I have a meter, but it's not handy unfortunately). I might need to adjust the calibration on the amp unbalanced inputs as well.

I'll give the above a shot and let you know - thanks.

Patrick Dixon
2005-10-27, 09:04
I've been listening to my modified SB2 very carefully over the last few days, and it has been troubling me that it didn't sound as good as I remembered.

It seemed to me that there was something wrong at the HF end which was making it sound a little harsh and fatiguing - a characteristic that I was sure was not there before.

So I ran some frequency sweeps through it (mainly to check that the response was flat), and I noticed a certain amplitude grantularity. This got me thinking that the new volume curve might be responsible (I've been using the SB2 direct to an amp with the SB2 volume control), and so I've been running some numbers through excel.

I'm not sure exactly how the 'linear' volume control was implemented, but assuming a 2.5% reduction in amplitude per step, volumes of 40, 35, 30, 25, 20, 15 etc would still produce 'lossless' results with 16 bit (CD-derived) sources. If SD implemented the intermediate volumes using 1/256 rounded coefficients, all the remaining volumes would have been lossless too.

However the new 'log' volume control uses 1.27dB reductions per step, which gives NO lossless volume settings - except for 40 (assuming 16 bit audio data).

So is this what I and jhwilliams + girlfriend are hearing? Well I've reverted to a pre-log-volume-control nightly, and I am convinced it sounds better.

So Sean, I have a suggestion. The log volume control is clearly a better approach overall, but could you implement a version that uses 1/256 rounded multipliers for (say) volumes 20-40, and non-rounded multipliers below? No critical listening can really take place at -25dB+ with 'normal' amp gains /speaker efficiency, so the levels below 20 (which can't be smoothly rounded in 1/256ths) don't really matter.

In the interests of bit-perfect audio and all that ....

seanadams
2005-10-27, 09:43
So Sean, I have a suggestion. The log volume control is clearly a better approach overall, but could you implement a version that uses 1/256 rounded multipliers for (say) volumes 20-40, and non-rounded multipliers below? No critical listening can really take place at -25dB+ with 'normal' amp gains /speaker efficiency, so the levels below 20 (which can't be smoothly rounded in 1/256ths) don't really matter.

In the interests of bit-perfect audio and all that ....

Sounds reasonable, but I'm not keen on diving in right this moment to change it - we'll look into it though.

sleepysurf
2005-10-27, 10:12
If this is gonna take a while to implement, any chance of posting the latest pre-log nightly/beta for us to revert back to, for comparison? Frankly, I too, have suspected something "ain't right" lately, but haven't had time to investigate.

Patrick Dixon
2005-10-27, 10:42
Sounds reasonable, but I'm not keen on diving in right this moment to change it - we'll look into it though.Thanks. I appreciate you must be pretty busy at the moment.

jhwilliams
2005-10-27, 17:43
However the new 'log' volume control uses 1.27dB reductions per step, which gives NO lossless volume settings - except for 40 (assuming 16 bit audio data).

So is this what I and jhwilliams + girlfriend are hearing? Well I've reverted to a pre-log-volume-control nightly, and I am convinced it sounds better.


Thanks for the tips Patrick.

On the back of that, I tried the new firmware at volume 40 - then attenuated using the calibration pots on the unbalanced inputs of my amp.

I think it sounded a lot better (albeit at relatively high volumes). Unfortunately I didn't have another person around to try something blind, but I will do so tonight.

jhwilliams
2005-10-27, 17:49
If this is gonna take a while to implement, any chance of posting the latest pre-log nightly/beta for us to revert back to, for comparison? Frankly, I too, have suspected something "ain't right" lately, but haven't had time to investigate.

Unfortunately I'm at work so I can't remember the exact files.

All I did, however, is take the sb2 firmware file from 6.1 (in the server/firmware directory iirc) - and put that file in the firmware directory of the 6.2 install.

There is a configuration file in the same firmware directory that defines which version is to be used - simply set that back to the old version.

You will lose your preamp control (even if the option is displayed). This wasn't a big issue on my setup.

(Works fine for me however the usual caveats apply!)

Jon

Music Machine
2005-10-29, 08:52
This is a very serious issue for some owners that put the Squeezebox in service as the primary source. Is there a bugzilla for this?

Regards

dean
2005-10-29, 11:57
It's not clear that there is an issue at all. We'd need a
reproducible case.

On Oct 29, 2005, at 8:52 AM, Music Machine wrote:

>
> This is a very serious issue for some owners that put the
> Squeezebox in
> service as the primary source. Is there a bugzilla for this?
>
> Regards
>
>
> --
> Music Machine
>

sbjaerum
2005-10-30, 01:39
So Sean, I have a suggestion. The log volume control is clearly a better approach overall, but could you implement a version that uses 1/256 rounded multipliers for (say) volumes 20-40, and non-rounded multipliers below? No critical listening can really take place at -25dB+ with 'normal' amp gains /speaker efficiency, so the levels below 20 (which can't be smoothly rounded in 1/256ths) don't really matter.

In the interests of bit-perfect audio and all that ....



Sounds reasonable, but I'm not keen on diving in right this moment to change it - we'll look into it though.

I don't know how the multiplication with gain is done in the firmware, but wouldn't the small server patch below do what Patrick suggests?

Steinar


Index: server/Slim/Player/Squeezebox2.pm
================================================== =================
--- server/Slim/Player/Squeezebox2.pm (revision 4942)
+++ server/Slim/Player/Squeezebox2.pm (working copy)
@@ -272,7 +272,12 @@
# Map a floating point dB value to a 16.16 fixed point value to
# send as a new style volume to SB2 (FW 22+).
my $floatmult = 10 ** ($db/20);
- return int(($floatmult * (1 << 16)) + 0.5);
+ if ($db >= -25) {
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);
+ }
+ else {
+ return int(($floatmult * (1 << 16)) + 0.5);
+ }
}

Patrick Dixon
2005-10-30, 02:39
It's not clear that there is an issue at all. We'd need a
reproducible case.There is definitely an issue, and it's easy to demonstrate/reproduce - the only question is whether you can hear it or not! I say I can, and jhwilliams has done blind testing which indicates that he and his girlfriend can too. I have now reverted to Firmware 15, which I'm happy with sound-wise.

The issue is that previously the volume control used an 8-bit multiplier coefficient which meant that the full resolution of 16-bit audio (which is of course what CDs are) was always retained within the 24-bit datapath of the SB2. The new log volume control uses a 16x16 bit multiplier which means that rounding errors are 'always' introduced, and these are unconcealed by the addition of any dither. It's surprising to me too that I can hear these artifacts, but I think it's the character of the noise (coupled with oversampling in the DAC?) that makes it stand out.

Even with the addition of dither (which may well be useful for the replay gain situation anyway), there is an audiophile arguement that says you should always preseve the S/N ratio of the original 16 bit signal where you can. Therefore I am simply suggesting that you 'tweak' the coefficients of volume control settings 20-39 to use 8-bit resolution rather using the full 16-bit resolution of the new multiplier. Much below vol 20, 8-bit coefficients are not enough to resolve the volume steps required, but at these levels the artifacts are unlikely to be an issue.

My calculations gave something like this below - so the volume changes would be negligeable with the adjusted coeffs. Just ANDing the 20-39 coeffs with 1100hex would probably give acceptable results.

vol 8-bit coeff 'new' dB 'old' dB

20 14 -25.2 -25.4
21 16 -24.1 -24.1
22 18 -23.1 -22.8
23 21 -21.7 -21.6
24 25 -20.2 -20.3
25 29 -18.9 -19.0
26 33 -17.8 -17.8
27 38 -16.6 -16.5
28 44 -15.3 -15.2
29 51 -14.0 -14.0
30 59 -12.7 -12.7
31 69 -11.4 -11.4
32 80 -10.1 -10.2
33 92 -8.9 -8.9
34 107 -7.6 -7.6
35 123 -6.4 -6.3
36 143 -5.1 -5.1
37 165 -3.8 -3.8
38 191 -2.5 -2.5
39 221 -1.3 -1.3
40 256 0.0 0.0

Patrick Dixon
2005-10-30, 03:07
I don't know how the multiplication with gain is done in the firmware, but wouldn't the small server patch below do what Patrick suggests?

Steinar


Index: server/Slim/Player/Squeezebox2.pm
================================================== =================
--- server/Slim/Player/Squeezebox2.pm (revision 4942)
+++ server/Slim/Player/Squeezebox2.pm (working copy)
@@ -272,7 +272,12 @@
# Map a floating point dB value to a 16.16 fixed point value to
# send as a new style volume to SB2 (FW 22+).
my $floatmult = 10 ** ($db/20);
- return int(($floatmult * (1 << 16)) + 0.5);
+ if ($db >= -25) {
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);
+ }
+ else {
+ return int(($floatmult * (1 << 16)) + 0.5);
+ }
}
Thanks Steinar, I will try it out.

Patrick Dixon
2005-10-30, 04:46
It probably should be whatever-the-perl-syntax-is{-25 <= $dB < 0} (we could make this -35 I think), otherwise the routine will affect replay gain too (if it's used there).

jhwilliams
2005-10-30, 05:32
There is definitely an issue, and it's easy to demonstrate/reproduce - the only question is whether you can hear it or not! I say I can, and jhwilliams has done blind testing which indicates that he and his girlfriend can too. I have now reverted to Firmware 15, which I'm happy with sound-wise.


Indeed - I wish I could quantify it, but I haven't had the time to delve deeper. Additionally I've messed with my setup so much lately I'd have to retest everything again.

I'm the same - on firmware 15 which is still quite noticably sharper to me. I was on the latest firmware for a while, and was messing with my setup for ages (moving my speakers about, etc). I was convinced that had cracked it, but then I moved back to 15 the difference was as apparent as ever.

Let me know regarding the perl you are looking at - however, I'm running 6.2 w/ firmware 15 so it seems more likely to be a firmware side issue (afaik?).

Jon

sbjaerum
2005-10-30, 05:49
It probably should be whatever-the-perl-syntax-is{-25 <= $dB < 0} (we could make this -35 I think), otherwise the routine will affect replay gain too (if it's used there).

OK, agree. Any listening tests yet?

Steinar

sbjaerum
2005-10-30, 05:57
Let me know regarding the perl you are looking at - however, I'm running 6.2 w/ firmware 15 so it seems more likely to be a firmware side issue (afaik?).

Jon

The perl patch works together with firmware versions with the new volume functionality. I don't remember at which version this went into the firmware.

Allthough the multiplication is done in the client, the gain-coefficient to multiply the samples with is calculated by the server. The patch tries to provide coefficients that avoids round-off problems in the multiplication.

If coefficients do not turn out to be the problem, there is a possibility that there is a bug in the implementation of the fixed-point multiplication in the firmware. But this is of course only speculations...

Steinar

Patrick Dixon
2005-10-30, 06:44
OK, agree. Any listening tests yet?

Steinar
I've had a short listen and I think it's good. I'd like to take some time to be sure.

dean
2005-10-30, 08:56
On Oct 30, 2005, at 1:39 AM, Patrick Dixon wrote:

>
>
>> It's not clear that there is an issue at all. We'd need a
>> reproducible case.

> There is definitely an issue, and it's easy to demonstrate/reproduce -
> the only question is whether you can hear it or not! I say I can, and
> jhwilliams has done blind testing which indicates that he and his
> girlfriend can too. I have now reverted to Firmware 15, which I'm
> happy with sound-wise.

Well, internally on the player, the old volume control and the new
volume control both change the same gain coefficient.

The old-style is a 1.7 fixed-point encoding and the new one is a
16.16. So, depending on the value of the gain, you may find rounding
errors, since the resultant value is truncated at 24-bits, but the
trade off is that you can have much smaller volume increments.

I can't argue that you can't hear the difference (folly in this
forum), but I do believe that it's mathematically correct and for the
vast majority of users the new volume curve is a benefit.

p.s. I found this article on dither very interesting: <http://
stereophile.com/features/705dither/>




>
> The issue is that previously the volume control used an 8-bit
> multiplier coefficient which meant that the full resolution of 16-bit
> audio (which is of course what CDs are) was always retained within the
> 24-bit datapath of the SB2. The new log volume control uses a 16x16
> bit multiplier which means that rounding errors are 'always'
> introduced, and these are unconcealed by the addition of any dither.
> It's surprising to me too that I can hear these artifacts, but I think
> it's the character of the noise (coupled with oversampling in the
> DAC?)
> that makes it stand out.
>
> Even with the addition of dither (which may well be useful for the
> replay gain situation anyway), there is an audiophile arguement that
> says you should always preseve the S/N ratio of the original 16 bit
> signal where you can. Therefore I am simply suggesting that you
> 'tweak' the coefficients of volume control settings 20-39 to use 8-bit
> resolution rather using the full 16-bit resolution of the new
> multiplier. Much below vol 20, 8-bit coefficients are not enough to
> resolve the volume steps required, but at these levels the artifacts
> are unlikely to be an issue.
>
> My calculations gave something like this below - so the volume changes
> would be negligeable with the adjusted coeffs. Just ANDing the 20-39
> coeffs with 1100hex would probably give acceptable results.
>
> vol 8-bit coeff 'new' dB 'old' dB
>
> 20 14 -25.2 -25.4
> 21 16 -24.1 -24.1
> 22 18 -23.1 -22.8
> 23 21 -21.7 -21.6
> 24 25 -20.2 -20.3
> 25 29 -18.9 -19.0
> 26 33 -17.8 -17.8
> 27 38 -16.6 -16.5
> 28 44 -15.3 -15.2
> 29 51 -14.0 -14.0
> 30 59 -12.7 -12.7
> 31 69 -11.4 -11.4
> 32 80 -10.1 -10.2
> 33 92 -8.9 -8.9
> 34 107 -7.6 -7.6
> 35 123 -6.4 -6.3
> 36 143 -5.1 -5.1
> 37 165 -3.8 -3.8
> 38 191 -2.5 -2.5
> 39 221 -1.3 -1.3
> 40 256 0.0 0.0
>
>
> --
> Patrick Dixon
>
> www.at-view.co.uk
>

sbjaerum
2005-10-30, 09:29
I think Patrick's point is that by selecting gain coefficients that are multiples of 1/256, no bits are thrown away when truncating to 24 bits. I think my patch above ensures that after multiplication, no bits need to be thrown away when truncating to 24 bits. With these coefficients, the gain multiplication is reversible, the original samples can be recovered because no bits were thrown away.

Steinar


On Oct 30, 2005, at 1:39 AM, Patrick Dixon wrote:

>
>
>> It's not clear that there is an issue at all. We'd need a
>> reproducible case.

> There is definitely an issue, and it's easy to demonstrate/reproduce -
> the only question is whether you can hear it or not! I say I can, and
> jhwilliams has done blind testing which indicates that he and his
> girlfriend can too. I have now reverted to Firmware 15, which I'm
> happy with sound-wise.

Well, internally on the player, the old volume control and the new
volume control both change the same gain coefficient.

The old-style is a 1.7 fixed-point encoding and the new one is a
16.16. So, depending on the value of the gain, you may find rounding
errors, since the resultant value is truncated at 24-bits, but the
trade off is that you can have much smaller volume increments.

I can't argue that you can't hear the difference (folly in this
forum), but I do believe that it's mathematically correct and for the
vast majority of users the new volume curve is a benefit.

p.s. I found this article on dither very interesting: <http://
stereophile.com/features/705dither/>




>
> The issue is that previously the volume control used an 8-bit
> multiplier coefficient which meant that the full resolution of 16-bit
> audio (which is of course what CDs are) was always retained within the
> 24-bit datapath of the SB2. The new log volume control uses a 16x16
> bit multiplier which means that rounding errors are 'always'
> introduced, and these are unconcealed by the addition of any dither.
> It's surprising to me too that I can hear these artifacts, but I think
> it's the character of the noise (coupled with oversampling in the
> DAC?)
> that makes it stand out.
>
> Even with the addition of dither (which may well be useful for the
> replay gain situation anyway), there is an audiophile arguement that
> says you should always preseve the S/N ratio of the original 16 bit
> signal where you can. Therefore I am simply suggesting that you
> 'tweak' the coefficients of volume control settings 20-39 to use 8-bit
> resolution rather using the full 16-bit resolution of the new
> multiplier. Much below vol 20, 8-bit coefficients are not enough to
> resolve the volume steps required, but at these levels the artifacts
> are unlikely to be an issue.
>
> My calculations gave something like this below - so the volume changes
> would be negligeable with the adjusted coeffs. Just ANDing the 20-39
> coeffs with 1100hex would probably give acceptable results.
>
> vol 8-bit coeff 'new' dB 'old' dB
>
> 20 14 -25.2 -25.4
> 21 16 -24.1 -24.1
> 22 18 -23.1 -22.8
> 23 21 -21.7 -21.6
> 24 25 -20.2 -20.3
> 25 29 -18.9 -19.0
> 26 33 -17.8 -17.8
> 27 38 -16.6 -16.5
> 28 44 -15.3 -15.2
> 29 51 -14.0 -14.0
> 30 59 -12.7 -12.7
> 31 69 -11.4 -11.4
> 32 80 -10.1 -10.2
> 33 92 -8.9 -8.9
> 34 107 -7.6 -7.6
> 35 123 -6.4 -6.3
> 36 143 -5.1 -5.1
> 37 165 -3.8 -3.8
> 38 191 -2.5 -2.5
> 39 221 -1.3 -1.3
> 40 256 0.0 0.0
>
>
> --
> Patrick Dixon
>
> www.at-view.co.uk
>

Patrick Dixon
2005-10-30, 10:01
Well, internally on the player, the old volume control and the new
volume control both change the same gain coefficient.

The old-style is a 1.7 fixed-point encoding and the new one is a
16.16. So, depending on the value of the gain, you may find rounding errors, since the resultant value is truncated at 24-bits My point is exactly as Steinar says.
... but the trade off is that you can have much smaller volume increments.I think this is one occasion where we can have our cake and eat it ;-)

Patrick Dixon
2005-10-30, 12:15
Steinar, I have just had the Rolling Stones around for tea - so I think your patch is good! Thank you very much. Can you tell me what the perl-speak is for -35 <= $dB < 0 and I will run with that.

Dean, I don't think the Stereophile dither article you linked to is quite analogous; it's refering to trunkating 24-bit sampled audio to 16-bits - so you still have a full 16-bits of actual 'real' data. With the SB2 volume control situation however, the division process ('cos that's what it actually is), is loosing the resolution of a 16-bit sample at the lsbs. I think this is why it's audiable. I don't think it applies to the replay gain situation, but I would have to think about it some more to be sure. I'm not using replay gain at the moment (but I would like to try it when I get time), so I can't do any listening tests to verify my theory.

seanadams
2005-10-30, 12:27
My point is exactly as Steinar says.I think this is one occasion where we can have our cake and eat it ;-)

Agreed, this makes sense.

If someone has the time it would be REALLY helpful to get verification that the new multiplier is correct. Make an AIFF that loops through a few hundred handom numbers, then play it on the old firmware and then on the new firmware with this patch. Record the s/pdif output and compare. I'd do it right now but I don't have the time just this moment. Thanks.

sbjaerum
2005-10-30, 12:46
Steinar, I have just had the Rolling Stones around for tea - so I think your patch is good! Thank you very much. Can you tell me what the perl-speak is for -35 <= $dB < 0 and I will run with that.

The below patch does that.

Steinar


Index: server/Slim/Player/Squeezebox2.pm
================================================== =================
--- server/Slim/Player/Squeezebox2.pm (revision 4942)
+++ server/Slim/Player/Squeezebox2.pm (working copy)
@@ -272,7 +272,12 @@
# Map a floating point dB value to a 16.16 fixed point value to
# send as a new style volume to SB2 (FW 22+).
my $floatmult = 10 ** ($db/20);
- return int(($floatmult * (1 << 16)) + 0.5);
+ if ($db >= -35 && $db <= 0) {
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);
+ }
+ else {
+ return int(($floatmult * (1 << 16)) + 0.5);
+ }
}

sub volume {

pfarrell
2005-10-30, 12:49
On Sun, 2005-10-30 at 11:27 -0800, seanadams wrote:
> Patrick Dixon Wrote:
> > My point is exactly as Steinar says.I think this is one occasion where
> > we can have our cake and eat it ;-)

> If someone has the time it would be REALLY helpful to get verification
> that the new multiplier is correct. Make an AIFF that loops through a
> few hundred handom numbers, then play it on the old firmware and then
> on the new firmware with this patch. Record the s/pdif output and
> compare.

Of course, we would then have to specify which dither algorithm to use.
My guess is that the audible difference would be fixed with any good
dithering algorithm. Dither is important.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

sbjaerum
2005-10-30, 13:00
If someone has the time it would be REALLY helpful to get verification that the new multiplier is correct. Make an AIFF that loops through a few hundred handom numbers, then play it on the old firmware and then on the new firmware with this patch. Record the s/pdif output and compare. I'd do it right now but I don't have the time just this moment. Thanks.

I don't think it is that straight forward. I'm not sure if there is any volume setting that multiplies with the same number in the old and new firmware.

The old firmware multiplies with a gain coefficient in 1.7 fixed-point format. The proposed patch multiplies with a gain that is effectively in 1.8 format.

There is thus a need for a new patch of Squeezebox2.pm before such an experiment can be performed.

Steinar

sbjaerum
2005-10-30, 13:53
If someone has the time it would be REALLY helpful to get verification that the new multiplier is correct. Make an AIFF that loops through a few hundred handom numbers, then play it on the old firmware and then on the new firmware with this patch. Record the s/pdif output and compare. I'd do it right now but I don't have the time just this moment. Thanks.


I don't think it is that straight forward. I'm not sure if there is any volume setting that multiplies with the same number in the old and new firmware.

The old firmware multiplies with a gain coefficient in 1.7 fixed-point format. The proposed patch multiplies with a gain that is effectively in 1.8 format.

There is thus a need for a new patch of Squeezebox2.pm before such an experiment can be performed.

Steinar

For verification of new vs. old firmware gain multiplication, I think the below patch would be useful. With this patch the same gain coefficient should be applied to the data both in old and new firmware. However, the firmware implementation is different, and that is what should be tested.

Unfortunately I have neither the equipment nor the time at the moment to do this. Hopefully someone else have...

Steinar

Index: server/Slim/Player/Squeezebox2.pm
================================================== =================
--- server/Slim/Player/Squeezebox2.pm (revision 4951)
+++ server/Slim/Player/Squeezebox2.pm (working copy)
@@ -272,7 +272,12 @@
# Map a floating point dB value to a 16.16 fixed point value to
# send as a new style volume to SB2 (FW 22+).
my $floatmult = 10 ** ($db/20);
- return int(($floatmult * (1 << 16)) + 0.5);
+ if ($db >= -35 && $db <= 0) {
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);
+ }
+ else {
+ return int(($floatmult * (1 << 16)) + 0.5);
+ }
}

sub volume {
@@ -286,17 +291,8 @@
# Old style volume:
my $oldGain = $volume_map[int($volume)];

- my $newGain;
- if ($volume == 0) {
- $newGain = 0;
- }
- else {
- # With new style volume, let's try -49.5dB as the lowest

- # value.
- my $db = ($volume - 100)/2;
- $newGain = dBToFixed($db);
- }
-
+ my $newGain = $oldGain << 9;
+
my $data = pack('NNCCNN', $oldGain, $oldGain, $client->prefGet("
digitalVolumeControl"), $preamp, $newGain, $newGain);
$client->sendFrame('audg', \$data);
}

dean
2005-10-30, 23:56
On Oct 30, 2005, at 11:15 AM, Patrick Dixon wrote:
> Dean, I don't think the Stereophile dither article you linked to is
> quite analogous; it's refering to trunkating 24-bit sampled audio to
> 16-bits - so you still have a full 16-bits of actual 'real' data.
> With
> the SB2 volume control situation however, the division process ('cos
> that's what it actually is), is loosing the resolution of a 16-bit
> sample at the lsbs.
Think of it as truncating 32 bit audio at 24 bits. Same principles
should apply, no?

Patrick Dixon
2005-10-31, 01:40
On Oct 30, 2005, at 11:15 AM, Patrick Dixon wrote:
> Dean, I don't think the Stereophile dither article you linked to is
> quite analogous; it's refering to trunkating 24-bit sampled audio to
> 16-bits - so you still have a full 16-bits of actual 'real' data.
> With
> the SB2 volume control situation however, the division process ('cos
> that's what it actually is), is loosing the resolution of a 16-bit
> sample at the lsbs.
Think of it as truncating 32 bit audio at 24 bits. Same principles
should apply, no?
Think of it as passing an analogue signal at half max amplitude through a digital system, and then boosting the analogue output signal to compensate - you will only have 90dBs s/n, rather than the theoretical 96dBs possible.

Patrick Dixon
2005-11-14, 12:35
I have filed this as bug 2557 http://bugs.slimdevices.com/show_bug.cgi?id=2557

As things stand, the patch above (which I have tested and works well) is not considered important enough to make it into 6.2.1 So if you think different, you'd better vote for it and/or add you comments fast!

dean
2005-11-14, 12:44
6.2.1 is likely to go out today, sorry it didn't make it.

netim3
2005-11-14, 12:47
I'd certainly like to see this patch incorporated.

Patrick Dixon
2005-11-14, 12:52
It's worth holding for this!

dean
2005-11-14, 12:59
I'm not entirely sure I understand the problem well enough to say
that this patch is correct.

(I realize that there has been some listening tests done and you like
it better, but I want to also make sure it's correct.)

Given that the Squeezebox has a 24 bit output, the rounding error
should be down at around at 138-144dB, not 90-96dB and I have a hard
time believing that the effect would be as obvious as you state at
that level.

sbjaerum
2005-11-14, 13:31
I'm not entirely sure I understand the problem well enough to say
that this patch is correct.

(I realize that there has been some listening tests done and you like
it better, but I want to also make sure it's correct.)

Given that the Squeezebox has a 24 bit output, the rounding error
should be down at around at 138-144dB, not 90-96dB and I have a hard
time believing that the effect would be as obvious as you state at
that level.

I am not sure how audible the difference is, but in my opinion it is "cleaner" to multiply with gain coefficients that does not lead to bits being lost because of rounding.

I suggest to modify the gain coefficients for volume settings from -30dB to 0dB so that the patch becomes:


Index: server/Slim/Player/Squeezebox2.pm
================================================== =================
--- server/Slim/Player/Squeezebox2.pm (revision 5190)
+++ server/Slim/Player/Squeezebox2.pm (working copy)
@@ -272,7 +272,12 @@
# Map a floating point dB value to a 16.16 fixed point value to
# send as a new style volume to SB2 (FW 22+).
my $floatmult = 10 ** ($db/20);
- return int(($floatmult * (1 << 16)) + 0.5);
+ if ($db >= -30 && $db <= 0) {
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);
+ }
+ else {
+ return int(($floatmult * (1 << 16)) + 0.5);
+ }
}

sub volume {


With this patch the differences between "trunk" gain and "patch" gain are listed below.
The differences are small, but again, I think the patch gain coefficients are "cleaner".
In my opinion, it can't hurt to use the patch gain.
The purists will be satisfied if it is applied...

Steinar


dB Trunk Patch
0 65536 65536
-1 58409 58368
-2 52057 51968
-3 46396 46336
-4 41350 41472
-5 36854 36864
-6 32846 32768
-7 29274 29184
-8 26090 26112
-9 23253 23296
-10 20724 20736
-11 18471 18432
-12 16462 16384
-13 14672 14592
-14 13076 13056
-15 11654 11776
-16 10387 10496
-17 9257 9216
-18 8250 8192
-19 7353 7424
-20 6554 6656
-21 5841 5888
-22 5206 5120
-23 4640 4608
-24 4135 4096
-25 3685 3584
-26 3285 3328
-27 2927 2816
-28 2609 2560
-29 2325 2304
-30 2072 2048
-31 1847 1847
-32 1646 1646
-33 1467 1467
-34 1308 1308
-35 1165 1165
-36 1039 1039
-37 926 926
-38 825 825
-39 735 735
-40 655 655
-41 584 584
-42 521 521
-43 464 464
-44 414 414
-45 369 369
-46 328 328
-47 293 293
-48 261 261
-49 233 233
-50 207 207

Patrick Dixon
2005-11-14, 14:34
Given that the Squeezebox has a 24 bit output, the rounding error
should be down at around at 138-144dB, not 90-96dB and I have a hard
time believing that the effect would be as obvious as you state at
that level.This is simply incorrect - the rounding error is at the 16th bit of a 16-bit audio signal, therefore it is at -90/96dB.

It's not just that I like it better - it's also that it's 'correct' to maintain the accuracy of the original digital data - in a similar way as it's 'correct' not to sample rate convert 44.1KHz audio to 48KHz (as some other manufacturers do). Even if you don't understand it and won't take my word for it, the difference between the 'rounded' volume multipliers and the unrounded volume multipliers is so slight that it cannot possibly have a negative effect!

dean
2005-11-14, 15:07
On Nov 14, 2005, at 1:34 PM, Patrick Dixon wrote:

>
>> Given that the Squeezebox has a 24 bit output, the rounding error
>> should be down at around at 138-144dB, not 90-96dB and I have a hard
>> time believing that the effect would be as obvious as you state at
>> that level.

> This is simply incorrect - the rounding error is at the 16th bit of a
> 16-bit audio signal, therefore it is at -90/96dB.
The output audio signal is 24 bits. The rounding error is at the
least significant bit there.

The source material is 16 bits and when you scale that value it
necessarily needs to be rounded to the output resolution.

> It's not just that I like it better - it's also that it's 'correct' to
> maintain the accuracy of the original digital data - in a similar way
> as it's 'correct' not to sample rate convert 44.1KHz audio to 48KHz
> (as
> some other manufacturers do).
It's a tradeoff between the accuracy of the gain control vs the
rounding error at the 24th bit.

> Even if you don't understand it and won't
> take my word for it, the difference between the 'rounded' volume
> multipliers and the unrounded volume multipliers is so slight that it
> cannot possibly have a negative effect!
Yet they can have a positive effect?

I can believe that it does sound better in some cases because you
would be rounding up the gain value. The oldest trick in the stereo
salesman's book is to turn up the volume to make something sound better.

I'm not trying to be difficult here, but I do want to understand this
before we make a change. Another proposal moved the 8 to 16 bit
threshold from -35db to -30dB. What's the right value for this?

sbjaerum
2005-11-15, 00:24
Dean Blackketter asked:
> Another proposal moved the 8 to 16 bit threshold from -35db to -30dB. What's the right value for this?

The reason why I suggested to stop the modified gain calculations at -30dB is that below this value repeated values start to appear.
In the list below, the patch is used all the way down to -50dB, and you can see when repeated values show up.

Steinar

dB | Trunk | Patch
0 | 65536 | 65536
-1 | 58409 | 58368
-2 | 52057 | 51968
-3 | 46396 | 46336
-4 | 41350 | 41472
-5 | 36854 | 36864
-6 | 32846 | 32768
-7 | 29274 | 29184
-8 | 26090 | 26112
-9 | 23253 | 23296
-10 | 20724 | 20736
-11 | 18471 | 18432
-12 | 16462 | 16384
-13 | 14672 | 14592
-14 | 13076 | 13056
-15 | 11654 | 11776
-16 | 10387 | 10496
-17 | 9257 | 9216
-18 | 8250 | 8192
-19 | 7353 | 7424
-20 | 6554 | 6656
-21 | 5841 | 5888
-22 | 5206 | 5120
-23 | 4640 | 4608
-24 | 4135 | 4096
-25 | 3685 | 3584
-26 | 3285 | 3328
-27 | 2927 | 2816
-28 | 2609 | 2560
-29 | 2325 | 2304
-30 | 2072 | 2048
-31 | 1847 | 1792
-32 | 1646 | 1536
-33 | 1467 | 1536
-34 | 1308 | 1280
-35 | 1165 | 1280
-36 | 1039 | 1024
-37 | 926 | 1024
-38 | 825 | 768
-39 | 735 | 768
-40 | 655 | 768
-41 | 584 | 512
-42 | 521 | 512
-43 | 464 | 512
-44 | 414 | 512
-45 | 369 | 256
-46 | 328 | 256
-47 | 293 | 256
-48 | 261 | 256
-49 | 233 | 256
-50 | 207 | 256

Patrick Dixon
2005-11-15, 02:04
On Nov 14, 2005, at 1:34 PM, Patrick Dixon wrote:

>
>> Given that the Squeezebox has a 24 bit output, the rounding error
>> should be down at around at 138-144dB, not 90-96dB and I have a hard
>> time believing that the effect would be as obvious as you state at
>> that level.

> This is simply incorrect - the rounding error is at the 16th bit of a
> 16-bit audio signal, therefore it is at -90/96dB.
The output audio signal is 24 bits. The rounding error is at the
least significant bit there.But this is the 16th bit of the sampled data - therefore the error noise has 16th bit significance - not 24th


The source material is 16 bits and when you scale that value it
necessarily needs to be rounded to the output resolution.Indeed, and that's fine as long as you don't start discarding resolution


> It's not just that I like it better - it's also that it's 'correct' to
> maintain the accuracy of the original digital data - in a similar way
> as it's 'correct' not to sample rate convert 44.1KHz audio to 48KHz
> (as
> some other manufacturers do).
It's a tradeoff between the accuracy of the gain control vs the
rounding error at the 24th bit.But the gain control accuracy is insignificant compared to the rounding error. How can you argue that you can't hear the difference between a rounding error at 16 bits (or 24 as you think it is), but want to preserve volume control accuracy to two decimal places of a dB?


> Even if you don't understand it and won't
> take my word for it, the difference between the 'rounded' volume
> multipliers and the unrounded volume multipliers is so slight that it
> cannot possibly have a negative effect!
Yet they can have a positive effect?YES!!!!


I can believe that it does sound better in some cases because you
would be rounding up the gain value. The oldest trick in the stereo
salesman's book is to turn up the volume to make something sound better.I'm completely aware of that; it was me that first suggested it to jhwilliams earlier in this thread before I listened properly and tracked this down, but it's not what is happening here.


I'm not trying to be difficult here, but I do want to understand this
before we make a change.I'm not trying to be difficult either - I'm trying to help you! I have patched my code and I'm perfectly happy that a) it's correct and b) it sounds correct, but I'm concerned for Slim Devices that you should release code with such a significant audio quality bug. I'm trying to help you avoid a mistake.

Another proposal moved the 8 to 16 bit
threshold from -35db to -30dB. What's the right value for this?The right value is one as low as possible, but where the resolution of the volume control is still sensible. Obviously if the volume multiplier is changing less than 1 bit (ie not changing!) between steps - it's time to ditch the modulo 256 bit. -35dBs is fine for this, I could live with -30dB because I never listen down at this level, but in the interests of 'getting it right' and pleasing the majority of your users, you should stick to -35dB. Or even better, the exact point at which the volume control mutiplier stops changing at modulo 256.


[EDIT]Looking at Stienar's posts above, it seems that -30dB is the correct point. He's run his number's using the real SS code (I assume), whereas I just made some assumptions and ran a excel spreadsheet - so I'd go with his numbers if I were you!

Patrick Dixon
2005-11-15, 02:46
OK, here's an expanded version of the simple illustrations I posted on the bug report.

I have used 2 simple systems - each consists of an ADC the output of which is lsb extended to 5-bits, a digital mutiplier, DAC and finally an analogue gain to compensate for the digital multiplier. In all cases, if the system is transparent, the output should be the same as the input and there would therefore be zero error.

Key to headings
-----------------
A input
B input as % of fs
C expand to 5-bits
D integerised div
E dac op as % of fs
F analogue gain
G ERROR


System 1
-----------
3-bit ADC, digital multiplier of 4, 5-bit DAC, analogue gain x4

A B C D E F G

7 87.50% 28 7 21.88% 87.50% 0.00%
6 75.00% 24 6 18.75% 75.00% 0.00%
5 62.50% 20 5 15.63% 62.50% 0.00%
4 50.00% 16 4 12.50% 50.00% 0.00%
3 37.50% 12 3 9.38% 37.50% 0.00%
2 25.00% 8 2 6.25% 25.00% 0.00%
1 12.50% 4 1 3.13% 12.50% 0.00%
0 0.00% 0 0 0.00% 0.00% 0.00%

Peak Error 0.00%
Input S/N 18.06 System S/N 18.06


System 2
---------
3-bit ADC, digital multiplier of 5, 5-bit DAC, analogue gain x5

A B C D E F G

7 87.50% 28 5 15.63% 78.13% 9.38%
6 75.00% 24 4 12.50% 62.50% 12.50%
5 62.50% 20 4 12.50% 62.50% 0.00%
4 50.00% 16 3 9.38% 46.88% 3.13%
3 37.50% 12 2 6.25% 31.25% 6.25%
2 25.00% 8 1 3.13% 15.63% 9.38%
1 12.50% 4 0 0.00% 0.00% 12.50%
0 0.00% 0 0 0.00% 0.00% 0.00%

Peak Error 12.50%
Input S/N 18.06 System S/N 12.04



As you can see, the first system, because it uses a modulo 4 multiplier and makes use of the 'extra' 2 lsbs in the system, produces no errors and the ouptut S/N ratio is the same as the sampled S/N ratio (3bits = 18dB)

System 2 however, doesn't use a modulo 4 multiplier and therefore produces rounding errors. The errors are, peak to peak, 1/8th of the full scale - ie the same as the original sampling error. Output S/N ratio is therefore halved to 12dB.


Obviously, you can extend the concept from 3-bits lsb extended to 5-bits, to 16/24-bits - you'll just have more numbers. The point is that the rounding error is significant at the lsb of the sampled signal NOT the lsb of the system.

I hope that helps - I don't know how better to explain it at the moment. If you want to hear the difference and you can't, you'll just have to get an a plane and come over here - I'll demonstrate it to you! Looser buys the beers ;-)

Patrick Dixon
2005-11-15, 02:56
And here's System 3. It's the same as system 2 but with a 5 bit ADC (rather than 3-bit) on the front.

You still get rounding errors, and the S/N ratio is still reduced, but because you have more resolution to start with, the overall S/N ratio at 16dB is only slightly less than System 1.

System 3 5-bit ADC, digital multiplier of 5, 5-bit DAC, analogue gain x5

A B C D E F G

31 96.88% 31 6 18.75% 93.75% 3.13%
30 93.75% 30 6 18.75% 93.75% 0.00%
29 90.63% 29 5 15.63% 78.13% 12.50%
28 87.50% 28 5 15.63% 78.13% 9.38%
27 84.38% 27 5 15.63% 78.13% 6.25%
26 81.25% 26 5 15.63% 78.13% 3.13%
25 78.13% 25 5 15.63% 78.13% 0.00%
24 75.00% 24 4 12.50% 62.50% 12.50%

Peak Error 12.50%
Input S/N 30.10 System S/N 16.12


(BTW, this is meant to illustrate why you will 'probably' get away with rounding if you use 24 bit audio data sources!)

LavaJoe
2005-11-15, 08:04
+ return int($floatmult * (1 << 8) + 0.5) * (1 << 8);


I'm not sure if performance matters here, but one thing to consider is that multiplying an integer by (1 << 8) is the same as shifting that int left 8 bits (and it may be more efficient, depending on optimization, etc.), so the line above could be:

+ return int($floatmult * (1 << 8) + 0.5) << 8;

-Joe

zybar
2007-01-28, 08:36
So was there a final resolution on this topic?

Was anything changed in a specific firmware or Slimserver release?

George