Are you using ReplayGain? If you are, be aware that the Sansa firmware defaults a 4.5db pre-amp, and the Rockbox starts at 0.0.

Nope.. ReplayGain is off - I made sure of that as soon as I got the Clip Zip.

Just installed Rockbox again. Played around with the low & high frequency 'shelves' and set up some loud peaks before the 800khz mark until close to distortion, used some precut to bring them back down... and still not even patch on the Sansa OF 01.01.18. Completely lacking the depth at the lower end to mid - which is easily the best thing about the OF sound.

It seems as though Rockbox is cannot 'drive' earphones as well as the OF.

Both OF and Rockbox have the exact same frequency response - ruler flat, no matter what phones they have to drive. There's no bass boost by default. With "default EQ" I guess you mean "normal EQ"? In the OF that means the EQ is turned off. It might indeed be that Rockbox is a bit quieter than the OF, but that's about the only difference.

Both OF and Rockbox have the exact same frequency response - ruler flat, no matter what phones they have to drive. There's no bass boost by default. With "default EQ" I guess you mean "normal EQ"? In the OF that means the EQ is turned off. It might indeed be that Rockbox is a bit quieter than the OF, but that's about the only difference.

Even though the frequency responses are the same regardless of impedance, it just seems that Rockbox handles the voltage output differently to the OF. Cans are driven by power (as well as sound wave frequencies) and even though both the OF & Rockbox may be sending the exact same frequencies to your headphones... the "current/voltage" regulated by the OF is giving the diaphragms in heaphones more juice.

Even though the frequency responses are the same regardless of impedance, it just seems that Rockbox handles the voltage output differently to the OF. Cans are driven by power (as well as sound wave frequencies) and even though both the OF & Rockbox may be sending the exact same frequencies to your headphones...

Power is the square of voltage, so if the voltages generated are identical, so must be the sound produced.

There are two possibilities here:

1) Something is different with your player compared to dfkt's.
2) There is no difference between the two firmwares.

I suggested running RMAA and filing a bug report if you noted a difference compared to dfkt's results. Did you try that?

'Cause if there are two things I don't like about this player, they're:

1) That it's not available with 16 or 32 GB of onboard memory; and
2) That there's no line-in jack, though I'm not sure where they'd put it if it had one.

I pulled down about 5GB of music before getting impatient and putting it on full shuffle of all tracks (thanks to the tip from the gentleman above).

What an amazing array of features. Channel config, dynamic range compression, a game of Doom if I want to put an IWAD on the thing, more EQ options than I understand, a built-in text file browser that Just Works when you navigate into a non-audio file...

The Clip zip manual is mostly working now (it's missing the graphics) so checking that is a good place to start. Combining that and a little bit of thought can extend the capabilities even further than.

Party mode essentially just locks playback. You can still raise and lower the volume though. If you make Party Mode one of the buttons on the Quick Screen you can quickly lock the player one handed. If you use dfkt's build from the first post in this thread, one of the patches he included, FS#9305 - Context sensitive backlight on key press, gives you a setting under Settings>General Settings>Display>LCD Settings that let's you change the volume without turning on the display.

Combine those settings with First Buttonpress Enables Backlight>No and you can lock the player one handed and turn the volume up and down without using up battery power turning on the display. I've found that to be very handy for one handed, blind operation

There's been any number of people that have wanted to lock the player one handed and have spent quite a bit of time asking developers to change the keymap to get it. If they dug into the settings they could easily roll their own.

I mangled Bertrik's Meier crossfeed patch horribly. Removed the old custom crossfeed, and implemented two versions of the Meier crossfeed in varying intensities. "Meier 1" is more subtle, "Meier 2" is the usual one that's already been in my older builds. Here's the hackish diff, if anyone wants to use it for their own builds: http://pastie.org/3233975

I mangled Bertrik's Meier crossfeed patch horribly. Removed the old custom crossfeed, and implemented two versions of the Meier crossfeed in varying intensities. "Meier 1" is more subtle, "Meier 2" is the usual one that's already been in my older builds. Here's the hackish diff, if anyone wants to use it for their own builds: http://pastie.org/3233975

Thanks for your updated patched builds.

One question about your mangled patch: The difference between the two cross feed functions seems only to be the coefficient used (0x2fffffff vs. 0x7fffffff). Why not use 1 function and provide the coefficient as an argument to the function? Just a thought that occurred to me while reading your patch.

That's because I unfortunately really don't have a clue about C programming. Best option would actually be to make the coefficient variable (1ff... to fff... or so), as a menu setting, in my opinion. I tried to write that, but unfortunately I lack the skills.

That's because I unfortunately really don't have a clue about C programming. Best option would actually be to make the coefficient variable (1ff... to fff... or so), as a menu setting, in my opinion. I tried to write that, but unfortunately I lack the skills.

Well, here's a straw-man, thoroughly untested version of what 7o9 proposed.

But does anyone feel that the sound is a little underpowered, less weighty compared to that of the Official Sansa Firmware?

This kind of complaint has appeared ever since the ClipV1 port. Just about all the issues that might deteriorate playback have been fixed though - pitch is pretty much dead on, output mixer AGC is off, headphone amp supply is same as on OF. RB in fact does a better job when it comes to recovering peaks exceeding fullscale.

The only glaring fault remaining is handling of sample rates other than 44.1 kHz, as DSP is fixed at that rate and anything else has to be resampled, which presently is done at lousy quality. So if you were using one of those lossy codecs that default to 48 kHz, results could be audibly worse... and they are very likely to be on audiobooks in the 16..24 kHz range.

Just bought an 8gb zip and thought it can be very interesting to use rockbox regarding the battery life improvement as I donīt really think I'll play too much with audio settings as I might get it sounding worse!

I think what you guys and people at rockbox ( If not the same ) are doing is simply amazing! thanks a lot.

One question that I have though is if the firmware differenciates wether the music is stored on the internal memory or SD card as original firmware does.

In rockbox, the external memory mounts as a folder in the root of the file system. You can play files directly from that folder, or else use the database which browses by tags and does not care about file location.

In rockbox, the external memory mounts as a folder in the root of the file system. You can play files directly from that folder, or else use the database which browses by tags and does not care about file location.

In other words, basically the same as the original firmware. I'm not sure how else it could be done.