Before buying: songs playing at a slower speed?

SanDisk MP3 players Sansa® Fuze™
121

It was reported months ago over at ABI that the V1 Clips played slightly off speed. I can’t remember if it was slow or fast. None of the audiofiles over there seemed to worry about it and they still rave about and recommend the Clip to others. Several firmware updates later and there has been no fix. I’m sure Sandisk is aware of the speed problem and probably they are not getting enough complaints to bother with it.

You can send all the emails you want and run all the tests you want, but nothing will probably come of it unless it is a simple fix. Head over to the Sansa View board and see how well Sandisk is supporting their flagship player that has a multitude of problems. There is no response from Sandisk over there at all and they still market the player.

The problem has been exposed, so sit back and wait to see what happens. I would not hold my breath on it though.

122

@davek wrote:

…

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)

…

Strange. I tested my V1 Fuze your 1k/44100/44100 and 1k/48000/48000 files as described here. I got measured frequencies of 1.00695kHz & 1.00445kHz respectively, which is consistent with my results from yesterday. I didn’t have my e260v2 with me today, so I haven’t tried them on it, but I imagine the results would be the same.

It’s interesting that you measure a low frequency & I measure high. I agree that it is probably a clock synth issue, and maybe there is a difference between V1 & V2 Fuze. I wonder whether it is a clock management issue. From discussion of other Fuze issues in the forum, it is appearent that the clock (in some aspects at least) is ramped down as far as possible to conserve battery energy. Sometimes it seems it is ramped too aggressively, giving playback problems.

I also measured my work PC, and an ancient Simatel MSCN player using my 10kHz MP3 VBR files. The PC played both 44100 & 48000 files at 9.9996kHz. The Sigmatel played them both at 10.0004kHz - impressive for a shoddy piece cheap tat!

I have to say this has never been a problem to me, I have never noticed it in practice. I only measured it out of curiosity (and because I could).

However, I could see that if one was trying to play music against a +0.7% error, it might well be noticable, depending on the type of music and so on.

123

@maxplanck wrote:

More technically knowledgeable people are drawing further attention to the problem and verifying that the magnitude is significant, better lock this thread too slotmonsta!   :smileyvery-happy:

 

Hey if I can get a time machine for you, you can go kill Magellan, then you can say that the earth is flat with real conviction!

@maxplanck wrote:
I admit that I can be short tempered when dealing with certain mentally retarded people, but only because I do believe that they are willfully stupid, and not genetically incapable of understanding. 

 

Anyway, I am moving this discussion over to the anythingbutipod forum, where hopefully those of us with technical knowledge can determine the extent of this problem without encumbrance from obstructionist ignoramuses.

Man, you’re definitely not helping.  Making things worse, if anything. 

124

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.  

Of course they use the PLL to clock the processor, which can’t run at 384 MHz. And 192 MHz would be far below the processors capabilities (think of video playback)

125

The processor core has its own pre and post dividers and can be run off of either of two PLLs or an external clock.  I don’t think this would be the main contraint.

126

@davek wrote:
The processor core has its own pre and post dividers and can be run off of either of two PLLs or an external clock.  I don’t think this would be the main contraint.

Didn’t know of the second PLL. If it is “lying around” this would be a solution. But at least when using the PLL clock you suggested, no divider would help (as I showed you in my previous post). Also what about USB? I would think, that needs a multiple of 480MHz. It is quite hard btw to add an external clock with a firmware update, isn’t it?

127

@calv wrote:

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.  

 

Of course they use the PLL to clock the processor, which can’t run at 384 MHz. And 192 MHz would be far below the processors capabilities (think of video playback)

 

 

 

One thing when choosing PLL frequency is that the player never has to do USB while playing music, or handle 48 and 44.1 sample rates at the same time.  

Message Edited by donp on 02-18-2009 11:15 AM

128

I <3 you guys, gah, science and thoughtfulness are such beautiful things *gets misty*

I’ll shut up now, sorry for interrupting

129

@calv wrote:

@davek wrote:
The processor core has its own pre and post dividers and can be run off of either of two PLLs or an external clock.  I don’t think this would be the main contraint.

Didn’t know of the second PLL. If it is “lying around” this would be a solution. But at least when using the PLL clock you suggested, no divider would help (as I showed you in my previous post). Also what about USB? I would think, that needs a multiple of 480MHz. It is quite hard btw to add an external clock with a firmware update, isn’t it?

Actually, there are fractional predividers such as 7/8, 6/8, 5/8 available in between the PLL(s) and the processor clock which has a maximum of 250MHz.  384*(5/8)/(1) = 240MHz processor clock.

You’re right that an external clock is not an option.  But even though the USB is tied to some multiple of 24MHz or 48MHz or 480MHz, the are other options.  It all depends on how the PLLs are being used and how the various peripherals are distributed among them.  Maybe it can’t be fixed without a large tear-up.  I’m just saying it would seem like the hardware is very flexible in this respect and probably capable of better.

130

We will look at adjusting clocks. Raising the PLL frequency will increase power consumption however.

131

Woot!  Thanks sansafix!!!

Now that I know that this issue can be resolved via firmware (see below), and likely will be resolved either by Sandisk or by Rockbox, I’m buying a Fuze. Thanks again to everybody who has helped shed light on and bring attention to this issue. I apologize to everyone I was impatient with, but as you can now see, this IS a legitimate issue.

sansafix wrote: 
Hi, its a battery life tradeoff. Running higher PLL will degrade battery life 5 - 7%.

Issue is logged and we will look into it again as time permits.
Message Edited by sansafix on 02-18-2009 10:03 AM

Message Edited by maxplanck on 02-18-2009 07:34 PM

132

All,

Good news, We have reduced the pitch error by one order of magnitude with little to no effect on battery life (<3%).

The optimization will be included in the next firmware release due out this quarter.

We have optimized for 44Khz and the pitch error is < 0.14%

For all other samples rates its <0.18%

Message Edited by sansafix on 02-19-2009 08:37 AM

133

Thanks Sansafix!

Just for my own information…could you tell me was the pitch error only on the V2 units and only on mp3 tracks?

BTW…When you say battery life do you mean the over all battery life expectany or power consumption and therefore more frequent charges? Perhaps both if the number of charges this battery type would take is several hundred a early death by the factor of 3% is acceptable…I’ll go back and check the forum for epected life details for the battery.

134

Thanks for the quick response!

I would recommend for the the musicians who have been complaining about off pitch playback to tune their instruments, go to their DAW software (Protools, Cubase, Ableton, etc.), pitch up a song by 0.14%, and play your instrument while playing back that pitched up song. Listen to hear if playback is close enough in pitch to your instrument to be acceptable. Then post back here to let us know.

It’s always a good idea to test with end users before release, so that problems like this don’t arise in the first place. I understand that, with the way corporate management tends to madly and blindly grasp for profit, appropriate testing may not be provided for in the budget. But certainly at least some small scale testing with users is almost always possible, even if it’s only unofficial and organized by the engineers alone. That will prevent problems like this from emerging in the first place (provided that the engineers listen carefully to the users, then redesign if necessary and retest until users give the *thumbs up*).

Operating this way (i.e. user testing and revamping the product until users give the *thumbs up* prior to release) is better for sales. You’ll get 5 star average reviews on Amazon, on user forums and by word-of-mouth. Sales will increase as a result.

It’s also better for society (less “junk” products on the market therefore less material and labor waste, less of users’ time wasted struggling with poorly designed products).

Edit:

bobletteross:  The unit will consume energy at a slightly faster pace with the fix. With the fix, a full battery charge will last ~3% less in terms of playback time, compared to how it is now. Whether that decreases the useful life of the unit depends on how you use it. (do you run the battery down to empty or recharge more frequently?, etc.) However, Li batteries seem to have an amazing lifespan, personally I’m not concerned.

The issue affects the playback speed of all audio file formats, since all audio files play back using the same clock mechanism. Pitch error will vary depending on the Sample Rate of the file, due to the nature of the clock mechanism.

I’m pretty sure that the pitch error occurs on all units of both the Fuze and the Clip, since it is a firmware issue. Since the V1 and V2 units have different firmware versions it’s possible that they may behave differently, but I would imagine that the relevant parts of the firmware code are similar if not identical.

Message Edited by maxplanck on 02-19-2009 10:54 AM

135

That is great news, Sansafix!  Will this apply to both the Fuze and the Clip?

Message Edited by davek on 02-19-2009 01:46 PM

136

Now I’m certain I remember why I prefer Sandisk products and always buy their brand when given the option.  I don’t mind paying more for quality.

The quality of Sandisk’s response to this disorder is superb.

Kudos! :slight_smile:

137

Don’t buy it!!!

138

@sansafix wrote:

Good news, We have reduced the pitch error by one order of magnitude with little to no effect on battery life (<3%).
The optimization will be included in the next firmware release due out this quarter.
We have optimized for 44Khz and the pitch error is < 0.14%
For all other samples rates its <0.18%

Thanks Sansafix,

That is even faster response than I had even dreamed possible. Thanks also to all my fellow buddies here who put forth their effort and opinions to demonstrate the customer perspective on this issue. I won’t miss the 3% in battery life, and will rest assured that the Fuze reproduces the tones in the music with an accuracy better than human hearing can discern.

139

@mptres wrote:
Don’t buy it!!!

Man, what’s your damage? Seriously, every single post I’ve seen by you says “Don’t buy it”, Get rid of the player as soon as you can", etc.  It’s a bit much, don’t you think?

140

Seriously, musicians who have been complaining about off pitch playback: I would recommend that you tune your instruments, pitch up a song by 0.14%, and play your instrument while listening to that pitched up song. Listen to hear if playback is close enough in pitch to your instrument to be acceptable. Then post back here to let us know.

The Sansa engineers are assuming that ~0.14% pitch error is going to be acceptable, but they are not musicians and have not tested this setting to make sure that it will be acceptable in a “playing your instrument alongside your Fuze” context. This is probably your last chance to have something done about it if +/-0.14% isn’t close enough, so you should test to make sure.

If you don’t know how to pitch up a file by precisely 0.14%, then PM me. You can send me your file, and I will pitch it up for you.

Message Edited by maxplanck on 02-19-2009 06:18 PM