android
  #1  
Old 02-18-2009, 12:01 AM
maxplanck maxplanck is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default Please help by running a test on your Fuze

Download this MP3 file:

http://www.mediacollege.com/audio/to...6bit_05sec.mp3

Copy the file to your Fuze. Play the file on your Fuze, and record the audio output from the Fuze to your computer. Upload that recording somewhere, and post a link to it here.

Please post your Fuze hardware revision # and firmware version. To find this:

Turn on your Fuze
Select Settings from the main menu
Select System Settings
Select Info
Read the Revision/Version # (6 digit number, looks like this: XX.XX.XX)



I am using this information in an effort to diagnose a "slightly slow or fast playback" problem which some users are experiencing.

Thank you very much
Reply With Quote

Advertisement [Remove Advertisement]

  #2  
Old 02-18-2009, 01:15 AM
tbone92's Avatar
tbone92 tbone92 is offline
Junior Member
 
Join Date: Feb 2009
Location: Dorr, MI
Posts: 80
Default

http://www.megaupload.com/?d=G1SL2KP7

Firmware: 02.01.17A

I left a couple seconds on there 'cause I didn't feel like trimming it down in Audacity. Hope that's ok.
Reply With Quote

  #3  
Old 02-18-2009, 01:50 AM
trms trms is offline
Junior Member
 
Join Date: Feb 2009
Posts: 1
Default My fuze plays correctly

Hi,

I played these files from Davek:
http://drop.io/clipspeedtest

And used jDFT (http://www.e.kth.se/~johk/jdft/download.html) to analyze the sound. Unfortunatelly I don't have jack-jack cable here so I played through amp & studio monitors and catched the sound by an integrated mic of my laptop. I know this can't be accurate but at least the result was for both files (44.1k and 48k) exactly the same - 1004.4Hz, which I think is pretty correct. I also didn't notice any pitch problems during normal playback.

My Fuze is V01.01.22F.
Reply With Quote

  #4  
Old 02-18-2009, 06:41 AM
davek davek is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default Test results

First results are interesting. tbone92's file clearly shows the 44.1kHz file playing back at 988Hz (-19.5 cents). This is the same thing I have observed on my v2 clip along with others.

trms seems to be hearing correct playback, but I'm not sure of the measurement technique. I'm not familiar with jDFT, but it's possible that, being FFT based, it may not be precise enough for this test. What's really called for is a schmitt trigger based frequency counter, or something similar. Or, maybe his v1 hardware/firmware combination does play at the correct pitch. I think more results are needed to sort out exactly what is going on.
Reply With Quote

  #5  
Old 02-18-2009, 09:16 AM
maxplanck maxplanck is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Yes, more test results are needed. Great work so far guys.

FFT/"Spectrum Analyzer" works fine for analyzing test results. Just read the frequency of the peak.

trms, can you find a jack-jack cable and record direct? Your results are important, I want to get a solid measurement. Thanks again.

Last edited by maxplanck; 02-18-2009 at 09:38 AM.
Reply With Quote

  #6  
Old 02-18-2009, 10:49 AM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,627
Default

FFT should be fine, just set the transform length to be really high (eg. at 48khz a 16k point fft gives you 3Hz resolution, which is way more then the human has available anyway).
Reply With Quote

  #7  
Old 02-18-2009, 11:01 AM
davek davek is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Be careful. Even though an 16k point FFT would give you 3Hz resolution, human hearing senses pitch logarithmically. Alternate tones between 40 and 43Hz. I believe you'll hear a difference--those frequencies are separated by more than an even-tempered semitone. At higher frequencies of course, an identical difference in Hz equates to a much smaller difference in perceived pitch.

I still think that it would be better to use a much more precise pitch detect/frequency counter algorithm for testing this behavior. FFT bins even at 32k are just too coarse--never mind window considerations, centricity of the tone within the bins, etc.
Reply With Quote

  #8  
Old 02-18-2009, 11:31 AM
maxplanck maxplanck is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Guys, please just post your Fuze audio output test files. We can discuss what constitutes an adequate file analysis method in another thread, I don't want this thread to get off topic. I have a method that works, so no need to worry much about it.
Reply With Quote

  #9  
Old 02-18-2009, 11:34 AM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,627
Default

Quote:
Originally Posted by davek View Post
Be careful. Even though an 16k point FFT would give you 3Hz resolution, human hearing senses pitch logarithmically.
Fortunately, this doesn't matter.

Quote:
Originally Posted by davek View Post
Alternate tones between 40 and 43Hz.
This would require an actual clock error of 7.5%. If its this high, theres no need for an FFT. Audio will sound wrong without the need for any testing.

Quote:
Originally Posted by davek View Post
I believe you'll hear a difference
Yes I believe massively screwing up the DAC clock would result in an audible difference.

Quote:
Originally Posted by davek View Post
I still think that it would be better to use a much more precise pitch detect/frequency counter algorithm for testing this behavior. FFT bins even at 32k are just too coarse--never mind window considerations, centricity of the tone within the bins, etc.
You're welcome to do that, but it provides you with nothing of value vs. an FFT.
Reply With Quote

  #10  
Old 02-18-2009, 12:51 PM
davek davek is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Quote:
You're welcome to do that, but it provides you with nothing of value vs. an FFT.
Actually, I think in this case it does. FFT based methods will tell you what bin the tone is in, but can't precisely quantize what the frequency is. It is the precise measurement of the frequency error which allows you to say something about what clock rates and dividers are being used.
Reply With Quote

  #11  
Old 02-18-2009, 01:35 PM
maxplanck maxplanck is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Good news, sansafix has identified the root cause of the issue, implied (as I understand it) that it can be fixed in a future firmware update, and says that "Issue is logged and we will look into it again as time permits."

http://forums.sandisk.com/sansa/boar...mp=true#M18120
Reply With Quote

  #12  
Old 02-18-2009, 01:38 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,627
Default

Quote:
Originally Posted by davek View Post
Actually, I think in this case it does. FFT based methods will tell you what bin the tone is in, but can't precisely quantize what the frequency is.
The DFT gives arbitrarily high frequency resolution. Certainly high enough for this application. Its not actually possible to give more information then a DFT on a shannon sampled signal, so no, it does not.

Quote:
Originally Posted by davek View Post
It is the precise measurement of the frequency error which allows you to say something about what clock rates and dividers are being used.
I was trying to be diplomatic here, but now I shall be blunt. You can't actually do better here then an DFT. This is provable.

You can actually do a lot worse. One way to do worse is to use a Schmitt trigger based frequency counter. Frequency counters are always a bad idea because they cannot approach the accuracy of Fourier based methods. They are sensitive to the bandwidth of the test signal being measured. A DFT is not. They are sensitive to out of band noise. A DFT is not. They do not provide Fourier limited accuracy. A Fourier method does. The fact that the theoretical accuracy limit is actually named after the fourier transform should be a clue that Fourier method is very accurate.

The method you propose here is little more then a crappy filter in front of a frequency counter. This is a dumb idea and why you think its worth doing is beyond me.
Reply With Quote

  #13  
Old 02-18-2009, 01:57 PM
davek davek is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Quote:
I was trying to be diplomatic here, but now I shall be blunt. You can't actually do better here then an DFT. This is provable.

You can actually do a lot worse. One way to do worse is to use a Schmitt trigger based frequency counter. Frequency counters are always a bad idea because they cannot approach the accuracy of Fourier based methods. They are sensitive to the bandwidth of the test signal being measured. A DFT is not. They are sensitive to out of band noise. A DFT is not. They do not provide Fourier limited accuracy. A Fourier method does. The fact that the theoretical accuracy limit is actually named after the fourier transform should be a clue that Fourier method is very accurate.

The method you propose here is little more then a crappy filter in front of a frequency counter. This is a dumb idea and why you think its worth doing is beyond me.
Understood. I've written code to implement a time variant DFT for order tracking of harmonic series so I'm aware of some of the issues you mention. All I really meant to say was that for the commonly available FFT-based tools, a user is limited in the number of bins and that the bins probably wont be centered on the frequency of interest. In other words, I couldn't tell from the developer's page whether the program mentioned, jDFT, would easily allow trms to differentiate between a pure tone that may plack back at either 1000.0Hz or 1001.6Hz or 988.7Hz. Not looking to start a fight and I don't really disagree with your points--just trying to get meaningful results in the context of this thread.
Reply With Quote

  #14  
Old 02-18-2009, 09:18 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,627
Default

Quote:
Originally Posted by davek View Post
Understood
No you haven't.

Quote:
Originally Posted by davek View Post
All I really meant to say was that for the commonly available FFT-based tools, a user is limited in the number of bins and that the bins probably wont be centered on the frequency of interest.
This doesn't make any sense. DFT bins are not centered over "the frequency of interest". They don't need to be since they cover all frequencies in the signal. Hell, you don't even get to pick a frequency of interest when you take a DFT.

Quote:
Originally Posted by davek View Post
In other words, I couldn't tell from the developer's page whether the program mentioned, jDFT, would easily allow trms to differentiate between a pure tone that may plack back at either 1000.0Hz or 1001.6Hz or 988.7Hz.
I don't care about whatever DFT program you're talking about. I'm just trying to get you to stop criticizing other people for doing the correct thing. You're in no position to be giving advice.
Reply With Quote

  #15  
Old 02-19-2009, 11:04 AM
davek davek is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Quote:
I don't care about whatever DFT program you're talking about. I'm just trying to get you to stop criticizing other people for doing the correct thing. You're in no position to be giving advice.
It's not my intent to criticize anyone here. I appreciate anyone taking the time to listen to or make measurements of the test file posted by maxplanck. I appreciate your knowledge and your work on RockBox, too.

I'm just saying that in the context of this playback speed issue, we're dealing with single frequency test tones and a more precise measurement of that tone helps to better understand the source of the error.

I may be completely wrong, but I don't understand how a 16k point DFT can measure the frequency of maxplanck's test tone beyond a precision of +/- about 3 Hz -- unless I'm missing something.
Reply With Quote

  #16  
Old 02-19-2009, 12:58 PM
maxplanck maxplanck is offline
Junior Member
 
Join Date: Feb 2009
Posts: 6
Default

Good news, fix is on the way:


"sansafix wrote:
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%"

http://forums.sandisk.com/sansa/boar...d=18197#M18197
Reply With Quote

  #17  
Old 02-19-2009, 03:04 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,627
Default

Quote:
Originally Posted by davek View Post
I may be completely wrong, but I don't understand how a 16k point DFT can measure the frequency of maxplanck's test tone beyond a precision of +/- about 3 Hz -- unless I'm missing something.
Well first, for his test tone, the best resolution a 16k DFT can give you is 0.12Hz, not 3Hz (formula is 2*bandwidth/bins).

What I said before was that at 48kHz you got 3Hz, but it depends on the sample rate you choose. I picked 48kHz because its a common value. Its actually not a very good value to choose since the test tone is only 1kHz.

More broadly speaking, you need to consider that the clock probably isn't stable to fractions of a Hz. It probably has a fairly wide fractional bandwidth, just because its a low power, low cost device. You just want to measure it to one part in a hundred or so. Any reasonable sized transform can do that.
Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -5. The time now is 06:52 AM.