Pitch bug on Clip+?

No the reason is the PLL Clock settings / dividers are less optimal for 44 Khz vs 48 Khz material.  Nothing is on the fly resampled.

You’re back?! Slotmonsta called you back?! Are you re-employed at SanDisk or just answering these questions as a helpful forum poster? I hope the former!

Welcome back sansafix!!

Just being helpful


@yelped wrote:


The man, the Legend!

Hello Sansafix!

Bob  :smileyvery-happy:

I guess everyone knows that even a cheapest junk mp3 player is able to play mp3s with correct pitch and that has nothing to do with the price. It seems to me that some terrible conceptual engineering mistake was made with clip series of players right from the start, when such a trivial problem persists and can’t be easily solved by software. In other words a hardware bug which can be fixed only by complete redesign - and that is expensive. I believe that’s what they meant with the official statement about this issue. Of course they are never going to admit something embarrassing like that…

Message Edited by m9zf3n5w on 10-12-2009 07:10 PM

No, that’s not the problem.  The Clip has a very limited power supply, due to physical constraints.  Despite this, we have a long operational life on a full charge.  This is possible by carefully managing the device’s power consumption. 

Decoding at various clock speeds is possible by modifying the PLL parameters and clock dividers.  This was done previously, as discussed.  Please take into consideration that the Clip and Fuze each have several different variants, the revision 1 and 2 families.  Each of these has a different configuration internally.

The Fuze has different display and memory requirements (TFT display and µSDHC socket), plus video.  The Clip has two revisions, plus the new Clip+ has integrated µSDHC capability.  The original Clips have the illuminated control buttons.

In short, it’s not just a matter of tinkering with the PLL algorithm, there are issues unique to each revision and device.  Note that the Clip+ is closer in measured speed.  Slotmonsta is right, there are many issues behind the scenes that affect the final firmware releases.  A far greater number of users would be upset if the battery life dropped considerably, I would bet.  A happy balance between processor demands and battery life is the “holy grail”.

Time permitting, future firmware revisions will get us closer to this goal.  And there are cool things “behind the scenes” too, that require time and effort.


Now that’s a teaser:  “cool things ‘behind the scenes’ …”


Thought you’d like that.  The Lil’ Monsta never sleeps…


  Are you trying to say that all other mp3 players on the market would have a longer battery life if they’ve chosen to play MP3s at wrong pitch ? :slight_smile: Or it is about wrong choice of components used (no native support for 44,1KHz), which is closer to my assumption.

Message Edited by m9zf3n5w on 10-13-2009 05:38 AM

Actually, you should market it as an audiophile feature. Wow-and-flutter is inherent to analog audio reproduction :) 

@m9zf3n5w wrote:

Actually, you should market it as an audiophile feature. Wow-and-flutter is inherent to analog audio reproduction :) 


*Ding* *Ding* *Ding* *Ding*

We have a winner!  Authentic analog reproduction of digital files exclusively from Sansa! Like having vinyl on a turntable in the palm of your hand!

Suck on that Apple and Sony…

@marvin_martian wrote:

Thanks for the link. Saratoga’s comment here makes sense and helps explain why Sandisk chose not to implement a pitch fix. The question is, who should be held responsible? Sandisk for choosing the chip, or AMS for creating a chip that requires a high clock speed for proper playback?

  If I got it right it’s all about sacrificing only 3% or less of advertised battery stamina in order to fix problem (by using values recommended by AMS). That’s hard to believe - battery stamina is such an inexact science (different volume usage patterns, different batches and constant deterioration of cells,  etc. etc.) that these 3% fall well into the tolerance inherent to battery technology, something which no one can complain about. However pitch error is very exact and very reproducible. On the top of all Sandisk need months to figure out how to find a compromise, again only because of the battery (I’d I understand if we are talking about hours, not minutes). Come on, either Sandisk can’t put together few good programmers, or it must be something more involved there (like bad design decisions).

Message Edited by m9zf3n5w on 10-13-2009 06:38 PM

@m9zf3n5w wrote:


An interesting take on the issue by Cnet, and the comments to the article.


So basically SanDisk is trying to say that the problem is a consequence of trade-offs involving a budget product. Well, everyone knows that engineering is about compromises, but what every technically inclined person knows is that this particular issue is so basic, that it doesn’t need to be part of it. If SanDisk is really honest about it, why don’t they just release concrete technical explanation (and shut our mouths up :)