PDA

View Full Version : 48 kHz/1536 kbps wav files



Xantia38
2005-07-01, 09:21
Hello,

I am encountering the following problem: when playing .wav files with 48 kHz/1536 kbps data rate, then the SB2 box plays them only at 44.1 kHz/1411 kbps, in other words the music plays approximately 10% slower.

Is this a know problem (I couldn't find anything in the bug reports)?

Which debug options can I use to determine what is going on? Is there a debug option which shows which commands are sent to the SB2 and how would I recognize the commands that tell the SB2 to use 44.1 and 48 kHz?

Technical details:
- SlimServer 6.02 running on a Windoes XP Pro PC as service.
- All my music files are encoded in .wav files and all metadata is in .cue files. Most files are in 44.1 kHz, some are in 48 kHz. The datarate is encoded in the wav file. The cue files don't have any reference to it (or should they?)
- The slimserver has all File Types disabled, except for file type "wav"/stream "wav".
- 2 SB2 boxes Firmware Version 11, both connected via Ethernet
- Database: MYSQL with all tables in utf8 encoding (not the default latin8)
- Except for this the system works fine.

I could check the database and all tracks are correctly marked as 48 kHz or 44.1 kHz. When using the server's d_parse debug option, I get entries like these two:

openSong: this is an wav file: file:///<long filename string>#4287.66666666667-4515.82666666667
file type: wav format: wav inrate: 1536 maxRate: 0

which seems to indicate that the 48 kHz datarate is correctly recognized.

Thanks for your help,
Xantia38

JulieL
2005-10-08, 07:01
Nine months on and Slim don't seem to have fixed this or even picked it up as an issue.

I have emailed Kevin at Slim, thought you might like to see my mail - I'll let you know what he says.

--------------------------------------------------------

Kevin, thanks

I did share your view about the pointlessness of upsampling until I read some of the audiophile sites talking about the fact it works, why it might work in theory (Nyquist cut off goes up from 22KHz to 24KHz) and then I tried it - it sounds loads better. (My theory is that the harmonics in 22-24KHz must be unconsciously audible, but my friend Paul thinks it’s something to do with “ghosting” – he has a £1,000 digital signal processor between his CD output stage and amp which he says makes a similar difference.)

Since I wrote to you I have purchased a SB2, and this has proved what I suspected – that the problem lies with the Slimserver software. I have also discovered this is a known bug – it’s discussed on the forum and features in one of your bug reports – searching on “48KHz plays slow” should call them up.

I will tell you what I know about this:

It is a bug in Slimserver streaming .wav as .wav files. The problem seems to be that Slimserver doesn’t recognize the sample rate and streams it at 44.1KHz anyway. I tested this by trying a number of different sample rates – 22KHz, 48KHz, 88.2KHz – they all play fast/slow in proportion to 44.1KHz (eg the 88.2KHz played at half speed.)

Using the FLAC converter – ie streaming .wav as FLAC – seems to correct the problem. Unfortunately, I can’t use this as a work-around as for some reason streaming as FLAC sounds terrible on my set up – it removes all the benefit of the lovely DAC in SB2 by making the sound muddy, fuzzy, lacking in detail. (As with upsampling, I appreciate that this is difficult to credit – that in theory the information is still the same as the original file - but obviously something in it matters a lot to the human ear.) I guess compression to MP3 would be a work around also, but obviously this will sound even worse than FLAC.

To compound the problem, the software doesn’t seem to be able to handle different bit-rates in .wav files either. Playing 20-bit or 24-bit files results in white noise.

I have attached an upsampled file at 48KHz, and the comparison sample original file at 44.1KHz, both 16-bit. (The files are huge – 15MB each.) Having researched the issue a bit more, I think it should work on both SB1 and SB2 (SB1 has a 48/16 DAC I believe) – as I say, I think you’ll find the issue is in the software.

This problem is a minor irritation to me – I’ll probably just send the SB2 back and forgot about audiophile quality digital for a while, just go back to vinyl for proper listening.

But I am writing you a long email about it because I think you ought to solve/escalate it before you lose the benefit of all the recent hard work on the audio side which has obviously gone into the SB2. The new DAC is great, and I can hear that with the right set up, it is finally something the audiophile community would adopt, no doubt boosting more mainstream acceptance. Unfortunately, the specification of the new DAC is currently way over what the Slimserver software is set up to use. This must surely be an easily solved problem requiring only once-off programming time, but it would make every piece of hardware you’ve sold function much much better.

Hope this helps. If you want me to help you test let me know.

Julie

PS If you listen to the files you’ll probably see what I mean about quality – the 48KHz has much better harmonics and spatial resolution. You may even be able to hear this on your PC – it must be fairly pronounced as my cloth-eared husband could hear the difference immediately.

-----Original Message-----
From: Kevin Pearsall [mailto:support@slimdevices.com]
Sent: 28 September 2005 23:59
To: Julie Lawrence
Subject: Re: Problem with streaming 48Mhz in SB1

Julie,

Sorry about the delay.

I don't know that 48kHz would work with SB1, but I could try this with SB2 if you could send me a sample file.

Also, I'm not sure that there should be any audible difference whatsoever upsampling from 44.1kHz to 48kHz, since you are basically just inventing data that was not there before. I would think that if anything, since you are adding new data to the audio, you're only adding distortion...

Regards,
Kevin P.

On Sep 22, 2005, at 5:12 AM, Julie Lawrence wrote:

I have an SB1 which I’m very happy with and a large collection (9000 tracks) ripped in .wav format CD-quality 44.1MHz 16 bit. My slimserver (version 6.1.1) plays these back very nicely streaming as WAV (but not streaming as FLAC where there is definite sound degradation). The network is wireless 54Mbps from PC to hub, then wired ethernet from hub to SB1.

Recently, I have been convinced that upsampling to 48MHz does improve sound quality, and I want to convert some of my files to 48MHz. But having tested it, I have a weird problem with slimserver (or perhaps with the SB1). The playback at 48Hz sounds great but is about 5% too slow/low. (I can’t just adjust pitch control to correct this as I’ll still need to play back 44.1MHz files and they would then sound too high.)

Slimserver is running on a fast PC, so I’m ruling out processing power as an issue. I’ve checked the 48 MHz files and played them back using other software (eg Winamp), as well as looking at them in DSP software - they are exactly the right speed. So I’m assuming there’s something about how slimserver or the squeezebox handles them which slows them down. Have you got any ideas how I can fix this. Am I right to rule out processing power as an issue? Would buying a 108Mbps hub or a SB2 make any difference?

Thanks in advance for your help.

Julie

Patrick Dixon
2005-10-08, 08:30
Julie,

I think it's actually 'only' 3 months on! Since Slim are American they insist on using arse-about-face dates on their forum ;)

I'm surprised and interested that you find 44.1KHz upsampled to 48KHz to sound so much better. I'm also slightly confused as to how you are listening to the 48KHz wav files, since the SB2 doesn't work with them! And I think your friend probably meant 'aliasing' rather than 'ghosting'. Upsampling to 48KHz can't add any more information (although there's no reason, if it's done correctly, why it should be any worse), but it can give you an extra couple of KHz to roll the reconstruction (anti-aliasing) filter off. However, the SB2's DAC already does 16 times (IIRC) oversampling, which takes the sampling frequency up to 705.6KHz - so the extra 2KHz of going to 48KHz is insignificant.

I'm also surprised that you find wav files to sound so much better than flac and I wonder if you are inadvertently streaming as mp3? Check that Player Settings->Audio->Bit Rate Limiting is set to 'No Limit' for your Player and that the Server Settings->File Types FLAC>FLAC box is checked. If you haven't already, you could also check if streaming 48KHz flac files as wav solves you problem (uncheck FLAC>FLAC and FLAC>MP3, and check FLAC>WAV in Server Settings->File Types).

We are about to release an audiophile version of the SB2 - see www.at-tunes.co.uk. It won't be cheap but it is good! If you'd like to hear it get in touch.

pfarrell
2005-10-08, 10:23
On Sat, 2005-10-08 at 08:30 -0700, Patrick Dixon wrote:
> I think it's actually 'only' 3 months on! Since Slim are American they
> insist on using arse-about-face dates on their forum ;)

It isn't just Slim, it is nearly all American dates.
It is arse-ackwards. As is using inches and feet and yards.

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

JJZolx
2005-10-08, 10:33
it is finally something the audiophile community would adopt, no doubt boosting more mainstream acceptance.
I consider myself an audiophile, but this is a little like saying that if head-hunters in New Guinea found the SB2 to their liking, it might then be sold at BestBuy. There's nothing mainstream about the audiophile community.

JJZolx
2005-10-08, 10:43
Hello,

I am encountering the following problem: when playing .wav files with 48 kHz/1536 kbps data rate, then the SB2 box plays them only at 44.1 kHz/1411 kbps, in other words the music plays approximately 10% slower.

Is this a know problem (I couldn't find anything in the bug reports)?
Is this bug #14 (opened 2003-12-18)?

http://bugs.slimdevices.com/show_bug.cgi?id=14


------- Additional Comment #11 From Vidur Apparao 2005-03-28 09:44 -------
The good news is that the use of sox addresses this for Ogg streams (see bug
699). and native FLAC decoding addresses this for FLAC files.

It's still the case that non-stereo/non-44.1KHz sample rate PCM files will play
incorrectly, but that's a server bug, not a client one. The client can now
accept mono/stereo, 8/16/32 bit, 8/11.025/12/16/22.05/24/32/44.1/48 KHz stream
(no stereo-swapped or uLaw/aLaw).
I don't get it. If it's been fixed on the client (SB2 only, from the sound of it) then what's there to fix on the server end? Wouldn't it just be a matter of recognizing the sample rate and telling the Squeezebox to play the stream at that rate?

machinehead
2005-10-09, 18:55
"Pat Farrell" <pfarrell (AT) pfarrell (DOT) com> wrote in
message news:1128792215.22093.19.camel (AT) m64 (DOT) pfarrell.com...
> On Sat, 2005-10-08 at 08:30 -0700, Patrick Dixon wrote:
>> I think it's actually 'only' 3 months on! Since Slim are American they
>> insist on using arse-about-face dates on their forum ;)
>
> It isn't just Slim, it is nearly all American dates.
> It is arse-ackwards. As is using inches and feet and yards.

I think when our ancestors threw off the yoke of the British Empire, they
just wanted to change a few things for spite. So they screwed around with
the dates, used commas in large numbers (e.g. one thousand is 1,000.00 in
the US and 1.000,00 elsewhere), and also they made ' mean feet and " mean
inches, instead of vice versa, much to the chagrin of Spinal Tap's
stagehands.

Not adopting the metric system is just us being lazy and stubborn. Gotta
have some fun when you're a superpower. ;-)

Ed

machinehead
2005-10-09, 18:59
"Patrick Dixon"
<Patrick.Dixon.1wlb0b (AT) no-mx (DOT) forums.slimdevices.com>
wrote in message news:Patrick.Dixon.1wlb0b (AT) no-mx (DOT) forums.slimdevices.com...
>
> I'm also surprised that you find wav files to sound so much better than
> flac and I wonder if you are inadvertently streaming as mp3? Check that
> Player Settings->Audio->Bit Rate Limiting is set to 'No Limit' for your
> Player and that the Server Settings->File Types FLAC>FLAC box is
> checked. If you haven't already, you could also check if streaming
> 48KHz flac files as wav solves you problem (uncheck FLAC>FLAC and
> FLAC>MP3, and check FLAC>WAV in Server Settings->File Types).

Agreed, there shouldn't be a difference, as the output of the FLAC decoder
should be identical to the WAV. There of course is no difference on a SB1,
since the decoding is done at the server, but there shouldn't be - and I
don't recall any others noticing - a difference on the SB2, either.

Ed

stinkingpig
2005-10-09, 20:38
machinehead wrote:

> ...
>
>I think when our ancestors threw off the yoke of the British Empire, they
>just wanted to change a few things for spite. So they screwed around with
>the dates, used commas in large numbers (e.g. one thousand is 1,000.00 in
>the US and 1.000,00 elsewhere), and also they made ' mean feet and " mean
>inches, instead of vice versa, much to the chagrin of Spinal Tap's
>stagehands.
>
>
>

not to mention spelling: here's some fun reading if you're bored.
*http://tinyurl.com/966ho*

>Not adopting the metric system is just us being lazy and stubborn. Gotta
>have some fun when you're a superpower. ;-)
>
>Ed
>
>

I'm American, and this one bugs me. Though I have to admit kilometers
always seem too small (vis a vis speedometers, highway signs). But if we
went metric we would get to say 'klicks' instead of kilometers, making
every discussion of a run to Costco sound like _The Bridge on The River
Kwai_.

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

seanadams
2005-10-09, 23:35
Since Slim are American they insist on using arse-about-face dates on their forum ;)

If I had my way, today would be 20051009. :)

Michel Fombellida
2005-10-10, 01:40
FYI See also bug #1859 it is perhaps related.

Michel

dean
2005-10-10, 20:33
That's ISO8601, sort of, which is my FAVORITE standard...

2005-10-09 (yesterday)


On Oct 9, 2005, at 11:35 PM, seanadams wrote:

>
> Patrick Dixon Wrote:
>
>> Since Slim are American they insist on using arse-about-face dates on
>> their forum ;)
>>
>
> If I had my way, today would be 20051009. :)
>
>
> --
> seanadams
>

Michaelwagner
2005-10-10, 21:02
I think it's actually 'only' 3 months on! Since Slim are American they insist on using arse-about-face dates on their forum ;)
Umm...on my browser, the dates show as:
1st July 2005, 12:21
Hard to say they insisted on a particular order since I seem to have gotten a setting for unambiguous dates ...

Michaelwagner
2005-10-10, 21:13
Not adopting the metric system is just us being lazy and stubborn.
But even the Europeans never completely went to 10 based things.
After all, I have no recollection of an hour being comprised of 100 minutae when I lived in Europe, nor, for that matter, were there ever other than 24 hours in a day.
I think we should have 10 hours in a day, each hour should have 100 minutes and each minute should have 100 seconds.

The second would be about 20% shorter than the current second, the minute about 33% longer, and the hour would be a lot longer, about 2.4 times longer than now. So most TV programs would be either half hour or quarter hour shows, and a one hour movie would be about as long as most people would have patience for.

Michaelwagner
2005-10-10, 21:20
If I had my way, today would be 20051009. :)I used to do it that way ... but it confused the hell out of everyone, even smart people.

Under my scheme, a timestamp for the last second of the day would be 9:99:99 or
99999 if you remove punctuation.

A much more dense representation than
11:59:59 PM or even than
235959.

A 16% space improvement - an entire digit spared. All those electrons freed to go and lead productive lives in other fields ... :-)