In terms of measurements, the Clip+ measures fairly quiet, but I only ran that test (I think) with the factory firmware. I might re-run it, if I get the chance, with the RB firmware with both the display on and off. I use a dScope audio analyzer with a noise floor below -140 dB so it should pick up *any* audible noise regardless of the type or source.
I know one of the developers that worked on the Rockbox port to the Clip+ hangs out on AnythingButiPod so it might be worth posting this question in the appropriate forum there. He seems to know the player inside and out.
And, finally, I don't think it's entirely fair to expect a $29 player (the basic Clip+ hardware in 2 GB form) to be the equal in every way of a multi hundred dollar iPod.
After reading several positive posts around here, I replaced my venerable iPod G5 Video with a little Sansa Clip+ and a 16GB flash card. Missing AAC support was a deal breaker, but Rockbox was reported to run fine.n issue, that I can't fix with whatever build, is annoying CPU noise. At the beginning of tracks and during rebuffering of longer tracks there is a short humming sound (like a bumblebee) mixed with a fast sequence of random high frequency tones. The sound differs as a function of data format and content. It is very homogeneous with WAV tracks (only humming) and different with lossy and lossless codecs. The same file encoded with FLAC and AAC leads to different short distortions. It is only audible for tracks with initial silence or very dynamic content, for example classical music with quiet passages or audio books. The original firmware does not show this behavior. It is probably a throttling issue. Rockbox just reads and decodes the file in a regular loop as fast as the CPU can deliver it. Due to cheap hardware design this leads to audible inference on the output. The original firmware probably works around this by some form of flow control and doesn't read the data any faster than required. But, as I've said, due to missing AAC support the original firmware is not an option.The phenomenon is only audible with my headphones. The Creative EP-630 have a rather large sensitivity of 106 dB. I tried to record the distortion over a line-input and it is non-existent there. That made me think about the common practice of shutting people up with RMAA results or telling them that what they hear must be placebo. High-impedance, line-level inputs do not necessarily capture the same as what a sensitive headphone outputs.
Maybe NwAvGuy can repeat the recording with his much better equipment. Then we would have an example.
I can try for a recording and measurement of the Clip+ running the last fully released RB version. If anyone wants to be more specific about exactly what they want recorded, and when they want it recorded (i.e. just as the clip starts, etc.), that would be useful?
As I have written, my ALC889's line-in is not sensitive enough to capture the noise. I guess the Clip+ drives it with a larger voltage than the IEMs and then its output is fine. I have uploaded my test file. It is nothing special, you could also just create your own, a mp3 with a forced high bitrate (so that it doesn't get buffered completely), with nothing but a high pitched tone inside. Copy it several times onto the SD card (not the internal storage) and then listen while you skip between tracks. The noise you hear is the same that annoys me during playback, when the SD card is accessed for re-buffering.
I don't see any need for sensitive measurements as the transients that are generated by my Clip+ with 01.02.15 firmware when I switch between 2 copies of the test file are pretty gross.
Heres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:http://duke.edu/~mgg6/rockbox/rockbox-patched.7z
Quote from: Arnold B. Krueger on 07 March, 2011, 11:02:46 AMI don't see any need for sensitive measurements as the transients that are generated by my Clip+ with 01.02.15 firmware when I switch between 2 copies of the test file are pretty gross.As I have repeatedly written, I'm totally fine with the sound quality of the stock firmware, which sadly leaves a lot to be desired with regard to supported codecs (not even AAC) and suitability for large audio book playlists. The short click between track transitions on the original firmware does not bother me, it also does not occur during rebuffering. It is unrelated to the reported issue.
Yes, that's impressive. If you find the time, I'd be interested in the same measurement with the Rockbox firmware.
To me a lack of gapless playback = broken.
On the Clip+/Rockbox there's a possibility to tweak the amplification between +/- 12dB:Settings->Playback Settings->Replaygain->Pre-amp.Maybe tweaking this can hide the noise a bit more?
Quote from: grums on 08 March, 2011, 02:30:44 PMOn the Clip+/Rockbox there's a possibility to tweak the amplification between +/- 12dB:Settings->Playback Settings->Replaygain->Pre-amp.Maybe tweaking this can hide the noise a bit more?That's just a digital volume knob, so I doubt it helps much. And it is only applied when ReplayGain is used on a file.
Quote from: saratoga on 07 March, 2011, 11:32:02 AMHeres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:http://duke.edu/~mgg6/rockbox/rockbox-patched.7zHi Saratoga.I finally got RB on my Clip+ thanks to the modified bootloader (my post on www.rockbox.org)I have now started playing with it, and instantly noticed this noise issue. I have no SD card installed. On track load, and what I assume is re-buffering (playing FLAC at the moment) I get random easily audible hiss/noise.I tried the latest stable, development and also this version, and all have the same issue. Just for your information as I couldn't see any feedback on this patched version.