Before buying: songs playing at a slower speed?

Has anyone checked if the difference they are hearing has anything to do with firmware vision? When I went from v01.01.11A to v01.01.22A on my 8GB Fuze  I thought there was a difference in sound quality, volume and pitch but the more I used it with the new firmware the more I got use to it…  I just got another 8GB Fuze with firmware v01.01.11A so when I have the time I will compare the two as best I can…  I do have two Set’s of the same Sony ear buds too. That will help…  I’ll post if I ever get   the time to do the tests… I have to admit I did not read all the posts about this so someone may have already done this test already… I must say I still enjoy the Fuse in any case… All that music in one small case with so many options!! I love it!  George   

@maxplanck wrote:

 

For musicians who use the Fuze, it’s a major issue, really a complete dealbreaker that makes the device useless for them if they can’t get the music to play at the correct pitch.

 

 

It amazes me how people cling to the anachronistic belief that “bad words,” in and of themselves, are harmful to anyone. Heaven forbid that a child hears a word that describes how s/he was created. We can’t have our children being too knowledgeable about the natural world around them, that would be “bad.”

 

Or heaven forbid that children hear a word that describes a material that everyone is well familiar with, which comes out of our rear ends every day.  

 

Words in and of themselves don’t harm people, it’s the way in which they’re used that can be harmful. To curse in frustration at pathological business practices doesn’t harm anyone, and in fact helps society by bringing attention to the problem of pathological business practices. 

 

When words are used in a threatening or demeaning manner, that is harmful to children and should be avoided.  I find it quite idiosyncratic that many people who would not use a “bad” word in front of a child, would not hesitate to threaten or demean that child if they “misbehave.”  Or that “bad” words are considered unsuitable for children to hear in media regardless of their context, while violence in media is considered suitable so long as the depiction of violence is sufficiently unrealistic (i.e. less gory with less harmful consequences than if the violent act were actually performed).

Message Edited by maxplanck on 02-15-2009 01:26 PM

Except for the first (one sentence) paragraph about musicians and Fuzes, how exactly is this rant about ‘bad words & children’ on-topic or relevant to this discussion?

What’s amazing is that some will use any excuse to jump on their soapbox to further promote their own agenda, whether it has anything to do with the conversation or not.

Mine was a 2.01.17 purchased just before Christmas at Radio Shack.

My fuze was replaced by a new Sony NWZ-e438f that reproduces tracks precisely on pitch and at identical speed to the same tracks played on all of my other devices.

@arranger wrote:

Mine was a 2.01.17 purchased just before Christmas at Radio Shack.

 

My fuze was replaced by a new Sony NWZ-e438f that reproduces tracks precisely on pitch and at identical speed to the same tracks played on all of my other devices.

Ladies and Gentlemen, I think we have the First step in the solution to the problem. The 2 people who have most activly pursued a solution to this issue, both have V2 fuzes. Is this the case for others who have this issue? My Guess is that it is. Does anybody know a way to tell what batch the fuzes are from? I wonder if they were all made at the same time?

@niko_sama wrote:

I finally read everything.  Interesting subject.   

I’d be interested in knowing more about the timing source used in the fuze/clip.

Now I’d like to test my devices and see how they rate.

 

I found my wife’s Chromatic tuner again and you guys sparked my interest so I made a few new test files using Audacity and tested them. The results are shown below.

  1. 440 Hz sine wave at 44100 sample rate encoded with LAME MP3 - 20 cents slow

  2. 880 Hz sine wave at 44100 sample rate encoded with LAME MP3 - 20 cents slow

  3. 440 Hz sine wave at 48000 sample rate encoded with LAME MP3 - dead on

  4. 440 Hz sine wave at 22050 sample rate encoded with OGG         - dead on

  5. 440 Hz sine wave at 96000 sample rate encoded with OGG         - dead on

There seems to be a pattern here. Does anyone want to comment.

Note that the real time clock is about 5 minutes slow - but I set it about a month ago.

p.s. I can hear a clear difference in pitch between these files.

Message Edited by Mp3Geek on 02-15-2009 07:00 PM

Wow, great work.  Could it be that Sandisk made a simple error and set the Fuze to play tracks normally recorded at 48kHz?  That would be quite a blunder, but one that might be easy to refirmware.

Great effort.

I’ve always been a proponent of replicating a problem, and working on a solution.  This gets me into trouble every time.

I love it, of course.

Looks like we see some correlations in the above posts too.  Remember, not every single issue is going to pop up during QA, as there are so many variables in that equation.

Perhaps, we can get some more confirmation of the rate and device revision.

Bob  :smileyvery-happy:

@tapeworm wrote:


@maxplanck wrote:

 

For musicians who use the Fuze, it’s a major issue, really a complete dealbreaker that makes the device useless for them if they can’t get the music to play at the correct pitch.

 

 

It amazes me how people cling to the anachronistic belief that “bad words,” in and of themselves, are harmful to anyone. Heaven forbid that a child hears a word that describes how s/he was created. We can’t have our children being too knowledgeable about the natural world around them, that would be “bad.”

 

Or heaven forbid that children hear a word that describes a material that everyone is well familiar with, which comes out of our rear ends every day.  

 

Words in and of themselves don’t harm people, it’s the way in which they’re used that can be harmful. To curse in frustration at pathological business practices doesn’t harm anyone, and in fact helps society by bringing attention to the problem of pathological business practices. 

 

When words are used in a threatening or demeaning manner, that is harmful to children and should be avoided.  I find it quite idiosyncratic that many people who would not use a “bad” word in front of a child, would not hesitate to threaten or demean that child if they “misbehave.”  Or that “bad” words are considered unsuitable for children to hear in media regardless of their context, while violence in media is considered suitable so long as the depiction of violence is sufficiently unrealistic (i.e. less gory with less harmful consequences than if the violent act were actually performed).

Message Edited by maxplanck on 02-15-2009 01:26 PM


 

Except for the first (one sentence) paragraph about musicians and Fuzes, how exactly is this rant about ‘bad words & children’ on-topic or relevant to this discussion?

 

What’s amazing is that some will use any excuse to jump on their soapbox to further promote their own agenda, whether it has anything to do with the conversation or not.

I was responding to your and conversion box’s complaints about my posting a link containing “bad” words.  You guys were the ones who first made an issue of the use of “bad” words, not me.  When I posted the link, I was operating under the assumption that we could all handle the use of some “bad” words without their use becoming an issue.

Message Edited by maxplanck on 02-15-2009 09:17 PM

@mp3geek wrote:


 


I found my wife’s Chromatic tuner again and you guys sparked my interest so I made a few new test files using Audacity and tested them. The results are shown below.

  1. 440 Hz sine wave at 44100 sample rate encoded with LAME MP3 - 20 cents slow
  1. 880 Hz sine wave at 44100 sample rate encoded with LAME MP3 - 20 cents slow
  1. 440 Hz sine wave at 48000 sample rate encoded with LAME MP3 - dead on
  1. 440 Hz sine wave at 22050 sample rate encoded with OGG         - dead on
  1. 440 Hz sine wave at 96000 sample rate encoded with OGG         - dead on

 

There seems to be a pattern here. Does anyone want to comment.

 

Note that the real time clock is about 5 minutes slow - but I set it about a month ago.

 

p.s. I can hear a clear difference in pitch between these files.

 

If other people who experience the problem can confirm that it always and only occurs when playing back MP3’s of 44100 Hz Sample Rate, then I think we’ve found the trigger.  If so, then my initial hunch was right *pats self on back*  :robotvery-happy:

Message Edited by maxplanck on 02-15-2009 10:25 PM

I am neutral on the arguments here and can agree with both sides. To people who won’t hear a difference, it won’t matter. To people that can’t have a difference it will matter. Here is my shot in the dark (unless it is a firmware problem)!

Have these v2 players been reformatted in Windows? There have been playback problems with wrong allocation block size during formatting of players and uSD cards. Format the player internally from it’s Settings Menu and see if it helps. It may or may not, but it is worth a try.

@maxplanck wrote:

If other people who experience the problem can confirm that it always and only occurs when playing back MP3’s of 44100 Hz Sample Rate, then I think we’ve found the trigger.  If so, then my initial hunch was right *pats self on back*  :robotvery-happy:

Well, I tested FLAC, OGG, MP3 and WAV formats, everything ripped from my own CDs using cdparanoia, encoders: flac, oggenc, lame. I even tested diffrent music styles (death metal, ambient, folk) - each of them played in the same, slower pitch (~2%). Later I reformatted the player using it’s own software and re-tested the files. Then I was sure, there’s something wrong. I returned it a few hours after I bought it through a warranty service and I’m still waiting for sandisk service to fix it (since February 3rd). BTW. that was a clip (v2, latest firmware, eastern europe)

P.S. 44100 sample rate

Message Edited by bungl on 02-16-2009 05:12 AM

@bungl wrote:



 

I tested FLAC, OGG, MP3 and WAV formats, everything ripped from my own CDs using cdparanoia, encoders: flac, oggenc, lame. I even tested diffrent music styles (death metal, ambient, folk) - each of them played in the same, slower pitch (~2%). Later I reformatted the player using it’s own software and re-tested the files. Then I was sure, there’s something wrong. I returned it a few hours after I bought it through a warranty service and I’m still waiting for sandisk service to fix it (since February 3rd). BTW. that was a clip (v2, latest firmware, eastern europe)

 

P.S. 44100 sample rate

OK, for bungl the problem occurs always and only when playing back all file types of 44100 Hz Sample Rate.  Thanks for testing bungl!

Now, can you other guys who have the Fuze confirm or deny this behavior on your own Fuze please.

Yep, all mine were playing off speed and all are 44.1KHz.  I won’t be ripping them over or converting them to 48kHz just to use a Fuze.  All my mp3s are tagged and image stamped.  That’s way too much work to make up for one of the Sandisk technogenius’ mishaps.

I sincerely hope that the defect is understood.  If so, I think it’s amazing that it took all of the consumers to sleuth it out and bring it to Sandisk’s attention.

I say Sandisk should fire all the staff and hire everyone who has posted on this thread.:smileyvery-happy:

Have the tests been made on the Fuze with early and late firmware visions installed? I was very happy with v01.01.11A as far as sound went… Hmmm   George

I just bought an 8G Fuze last night with the intention of using it to practice bass guitar.

I immediately noticed it was playing music too slowly, about 1 to 1.5 % slow.  I can tell

because my bass is tuned properly, but songs that I was able to play along with on my

old MP3 player (Sansa C240) now sounded out of tune compared to the bass. 

Wish I had read about it here first.  It’s going back to Best Buy.  Too bad, I really liked

the unit otherwise. 

I’m a Software Engineer and Hardware Engineer and have worked on embedded electronics

doing audio.  It’s completely unforgiveable to have this much error on their playback speed.

Any cheap crystal is easily capable of less than 100ppm, which is an error of only 0.01%. 

Mine is Vesion V02.01.09A.

MX21, mind running our little test before returning your unit and posting your results in the thread linked to below?  The test description is there. 

http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&message.id=17956#M17956

Message Edited by maxplanck on 02-16-2009 05:46 PM

Ok, I did the test and posted in the other thread.  My Fuze is definitely slow.

I’ve got a V2 8GB Clip, and I noticed the slow playback also.  Once you hear it, it can be extremely annoying.  After doing some testing with sine wavs and different encodings, I came up with the following measurements:

1000Hz sine wave encoded with LAME 44.1kHz ->  988.8Hz actual measured output frequency (-19.5 cents)

1000Hz sine wave encoded with LAME 48kHz    ->  1001.6Hz actual measured output frequency (+2.77 cents)

After getting the datasheet for the SoC used in this family of players, I took a look at their clock generation documentation.  The I2S audio clock (mclk) appears to be derived from a PLL which runs at a multiple of the 24MHz crystal oscillator.  It should be noted that the 24MHz crystal frequency is common for devices with USB functionality, but it is not optimal for the generating the common audio sampling frequency clocks.  The PLL is divided down by an integer ratio to get the mclk which runs at 128x the sampling frequency. 

If you do the math for the possible multiplier/dividers, there appears to be only one likely scenario of clock ratios that would result in this combination of playback speed errors.  

It appears like the PLL is being configured to 240Mhz.  The clock dividers I’m guessing they’re using are below:

44.1kHz playback:  240MHz PLL / 43 / 128 = 43605Hz (-19.56 cents compared to 44100Hz)

48kHz playback:    240MHz PLL / 39 / 128 = 48077Hz (+2.77 cents compared to 48000Hz)

In retrospect, since the vast majority of MP3s are encoded with a 44.1kHz sampling rate, it may have been better to choose a different PLL frequency and different divider ratios that minimize the playback speed error at 44.1kHz.  

384MHz / 68 / 128 = 44118Hz (+0.69 cents compared to 44100Hz)

Perhaps they have other constraints becuase of other peripherals being clocked off of the same PLL.  I don’t know.  It would seem, though, that all V2 clip/fuze should be affected.  It would also seem that it should be possible to fix this via a firmware upgrade.  

I wish it would be fixed.  The prospect if re-ripping and re-encoding my catalog @48KHz sampling rate to hear more accurate playback pitch is daunting and shouldn’t be necessary.  

Message Edited by davek on 02-17-2009 08:30 AM

Thank you, davek.  Your treatese is marvelous and clearly defines the problem.  I’m going to carefully look at my other (non-Sandisk) players and determine if pitch is affected in a similar yet more subtle way.

I believe that Sandisk also owes you about $100,000 for the retooling parameters on their next technology. 

@davek wrote:

I’ve got a V2 8GB Clip, and I noticed the slow playback also.  Once you hear it, it can be extremely annoying.  After doing some testing with sine wavs and different encodings, I came up with the following measurements:

 

1000Hz sine wave encoded with LAME 44.1kHz ->  1001.6Hz actual measured output frequency (-19.5 cents)

1000Hz sine wave encoded with LAME 48kHz    ->  988.8Hz actual measured output frequency (+2.77 cents)

 

After getting the datasheet for the SoC used in this family of players, I took a look at their clock generation documentation.  The I2S audio clock (mclk) appears to be derived from a PLL which runs at a multiple of the 24MHz crystal oscillator.  It should be noted that the 24MHz crystal frequency is common for devices with USB functionality, but it is not optimal for the generating the common audio sampling frequency clocks.  The PLL is divided down by an integer ratio to get the mclk which runs at 128x the sampling frequency. 

 

If you do the math for the possible multiplier/dividers, there appears to be only one likely scenario of clock ratios that would result in this combination of playback speed errors.  

 

It appears like the PLL is being configured to 240Mhz.  The clock dividers I’m guessing they’re using are below:

 

44.1kHz playback:  240MHz PLL / 43 / 128 = 43605Hz (-19.56 cents compared to 44100Hz)

48kHz playback:    240MHz PLL / 39 / 128 = 48077Hz (+2.77 cents compared to 48000Hz)

 

In retrospect, since the vast majority of MP3s are encoded with a 44.1kHz sampling rate, it may have been better to choose a different PLL frequency and different divider ratios that minimize the playback speed error at 44.1kHz.  

 

384MHz / 68 / 128 = 44118Hz (+0.69 cents compared to 44100Hz)

 

Perhaps they have other constraints becuase of other peripherals being clocked off of the same PLL.  I don’t know.  It would seem, though, that all V2 clip/fuze should be affected.  It would also seem that it should be possible to fix this via a firmware upgrade.  

 

@I wish it would be fixed.  The prospect if re-ripping and re-encoding my catalog @48KHz sampling rate to hear more accurate playback pitch is daunting and shouldn’t be necessary.  

*applauds*

*standing ovation*

*applause continues*

Isn’t science great? We don’t have to “just live with it” and tell ourselves “it’s not that bad” when actually it is bad. We can solve our problems, if we’re willing to take action.

I forwarded DaveK’s post, along with links to this thread and the test results thread, to Sansa with instructions to forward my email to their engineering department. If you guys will do the same, we can generate enough of a ruckus to get this fixed.

Message Edited by maxplanck on 02-17-2009 08:38 AM