I hate talking about this because it causes so many arguments . . .
But since I don’t know anything about programming, why is it so hard to take a small gap out from two songs?
Its not very hard. My theory is that since most companies buy commercial MP3 decoders rather then write their own, they can’t add support for new features easily or at all without buying new decoders. They probably just don’t want to spend the money to do it.
For Rockbox its easy to do things like this, since I and others have already rewritten so much of the codecs to suit our needs. We can make them do whatever we want.
I should have said “if” it impacts battery life. I don’t know the programming end. I imagine it would require some extra buffering. I only brought it up because Sansa had responded to the pitch issue having an impact on battery life and seemed that was the reason they did not perfect it. They may be able to get gapless right-on with only some tweaking, I really don’t know.
If anything it’ll save you a tiny bit of battery life, since each file is now a couple milliseconds quicker to decode
Reality is best improved with a decent cup of coffee, an Australian Shepherd at your feet (he’s upside down currently, paws in the air), and a Sansa playing Evening Mist by Riley Lee. Awesome Japanese flute work. I’m collecting my chi as we speak. Very nice.
Corporations are a collective instrument, made by humans with a common goal. And they provide employment opportunities too, fancy that.
Bob :smileyvery-happy:
Message Edited by neutron_bob on 02-07-2010 10:30 AM
The battery life EXCUSE is a blatant lie. Rockbox implements gapless and IMPROVES battery life.
Corporate lies never did cut it for me.
Message Edited by roj on 02-06-2010 07:35 PM
The battery life comments were a reference to the pitch issue with the Sansas, not the gapless issue. Read a little more closely before ratcheting up your indignation.
The battery life EXCUSE is a blatant lie. Rockbox implements gapless and IMPROVES battery life.
Have I missed something? Unless it’s come about recently (and I have to admit, I haven’t really kept up with it of late) Rockbox firmware has always used more battery power, shortening battery life.
Battery: battery life is shorter than when using the OF, see SansaRuntime
And unless I’m reading it wrong, the gapless playback Rockbox supports is only ‘iTunes-encoded .mp3 files’. I don’t know about you, but I have exactly 0% of my music encoded through iTunes.
And unless I’m reading it wrong, the gapless playback Rockbox supports is only ‘iTunes-encoded .mp3 files’. I don’t know about you, but I have exactly 0% of my music encoded through iTunes.
The battery life EXCUSE is a blatant lie. Rockbox implements gapless and IMPROVES battery life.
Have I missed something? Unless it’s come about recently (and I have to admit, I haven’t really kept up with it of late) Rockbox firmware has always used more battery power, shortening battery life.
Battery: battery life is shorter than when using the OF, see SansaRuntime
And unless I’m reading it wrong, the gapless playback Rockbox supports is only ‘iTunes-encoded .mp3 files’. I don’t know about you, but I have exactly 0% of my music encoded through iTunes.
You missed something.
Either that or someone forgot to explain that to my Cowon X5 when I tried it three years ago.
You missed even more with the gapless weirdness.
It supports mp3s encoded with LAME versions that support gapless (LAME implemented that a LONG tme ago) which thankfully has absolutely nothing to do with iCrap.
Just checking back in after many months waiting for gapless. Doesn’t appear to be any change unless I missed something. I’m truly disappointed in this product and Sandisk’s inability to respond to customer requests.
I guess the only thing I can say is that if I’d known about the gaps before buying I would have looked for a better product. And certainly I’ll be skipping Sandisk in the future.
As a listener to Classical/Opera music it’s just total ■■■■ to have to put up with gaps. About half the music I listen to is botched up by the gaps. Anyhting in opera is ruined and quite a range of 20th century music like “Stravinsky’s Rite of Spring” and many, many others require gapless playback.
I get more than 1 second gaps on mine despite what some others are saying.
Have I missed something? Unless it’s come about recently (and I have to admit, I haven’t really kept up with it of late) Rockbox firmware has always used more battery power, shortening battery life.
You’ve missed a lot. Rockbox usually gets a lot better battery life then the original firmware.
I’ve put quite a bit of time into making sure my e200 gets much better life now then when I bought it :)
Battery: battery life is shorter than when using the OF, see SansaRuntime
Might want to click that link of yours and take note of all the e200v1 benchmarks that are hours ahead of the Sandisk firmware before you say “always”. Battery life on AMS is lower due to a bug in some of the AMS drivers. Thats not really a rockbox problem though, just a case of no one having figured out how to correctly use the AMS CPU yet. It was the same with the e200v1. When I started it got about 10 hours life. After some more work and reverse engineering, its about 24 hours (assuming a new battery).
Tapeworm wrote:
And unless I’m reading it wrong, the gapless playback Rockbox supports is only ‘iTunes-encoded .mp3 files’. I don’t know about you, but I have exactly 0% of my music encoded through iTunes.
Yes, you’re reading it wrong. Apple recently added a new and incompatible way of doing gapless encoding. We updated the decoder to support it. Presumably you are reading the rockbox 3.5 release notes to say that no version of rockbox was gapless before this month, which is not the best way of reading them.
Might want to click that link of yours and take note of all the e200v1 benchmarks that are hours ahead of the Sandisk firmware before you say “always”. Battery life on AMS is lower due to a bug in some of the AMS drivers. Thats not really a rockbox problem though, just a case of no one having figured out how to correctly use the AMS CPU yet. It was the same with the e200v1. When I started it got about 10 hours life. After some more work and reverse engineering, its about 24 hours (assuming a new battery).
You are probably correct, but since the subject of this discussion is Rockbox on the Fuze , the e200v1 specs don’t really apply, do they? I’ll be more careful in my use of the word ‘always’ from now on.
saratoga wrote:
Yes, you’re reading it wrong. Apple recently added a new and incompatible way of doing gapless encoding. We updated the decoder to support it. Presumably you are reading the rockbox 3.5 release notes to say that no version of rockbox was gapless before this month, which is not the best way of reading them.
Yes, that is what happened (reading the 3.5 release notes). I remembered the LAME encoded MP3 gapless feature being available before (on the e200v1 series), but realized this after posting. Other things kept me from coming back and editing my post (cooking some of my ‘Colon-Buster’ chili for the big game)
Might want to click that link of yours and take note of all the e200v1 benchmarks that are hours ahead of the Sandisk firmware before you say “always”. Battery life on AMS is lower due to a bug in some of the AMS drivers. Thats not really a rockbox problem though, just a case of no one having figured out how to correctly use the AMS CPU yet. It was the same with the e200v1. When I started it got about 10 hours life. After some more work and reverse engineering, its about 24 hours (assuming a new battery).
You are probably correct,
Probably correct? Its your link. Stop wasting everyones time and read it already.
Tapeworm wrote:
since the subject of this discussion is Rockbox on the Fuze , the e200v1 specs don’t really apply, do they?
Well you brought it up, so I can’t really say what you were thinking . . .
The point is that there will hopefully be further improvements to battery life as development goes on, hence the e200v1 example. It’s a long process, and I for one am very grateful for the time they put into rockbox development.
Probably correct? Its your link. Stop wasting everyones time and read it already.
Easy there . . . I did read it. I see only 1 instance where Rockbox firmware provided more battery life than the OF in the e200v1 series. This is out of 20 run tests. Granted these tests are at least a year old, and most do not give the OF run-time as a comparision, but even the newer tests on the v2 and Fuze do not support Rockbox providing increased battery life over the OF. Maybe if newer results prove the contrary, they should be posted and the wiki updated.
As I said, for the discussion in this thread the e200v1 results are irrelevant, but I don’t see anything to support what you & others have said that Rockbox = more battery life. If you’ve got other evidence to link to, great. I’m all for more battery life and am certainly not trying to start an argument.
THere was at least one change last year (all those e200 tests are from 2008) to increase battery life, suppressing screen animations (scrolling text, progress bar, anything just “deco”) when the back light times out.
It’s tough to compare different runs directly unless you know the batteries were in roughly the same condition, plus there are different formats and bit rates. As a general trend though, the times in those 2008 runs increased with the version number from low teens to near 20 hours, while the OF runs were all in the 14-15 range.
Easy there . . . I did read it. I see only 1 instance where Rockbox firmware provided more battery life than the OF in the e200v1 series.
Theres actually 2.
Tapeworm wrote:
This is out of 20 run tests.
You mean 3 comparing the OF and RB. The other tests do not do that.
Again, I’m going to suggest that you just read the page. It’ll take you maybe 30 seconds. Or if you’re really unwilling to do so, just take my word for it. I actually do know better then you here, so you can’t lose by listening to me. But its really annoying to have you both unwilling to read for yourself and unwilling to listen to me. Running around with your eyes closed and fingers in your ears screaming “I SEE AND HEAR NOTHING” is not a good way to win an argument or to save face once you realize you can’t win.
Tapeworm wrote:
As I said, for the discussion in this thread the e200v1 results are irrelevant,
Are you complaining to me that you brought up something you consider irrelevant? Maybe you shouldn’t have brought it up.
Tapeworm wrote:
I don’t see anything to support what you & others have said that Rockbox = more battery life.
Tapeworm wrote:
I see only 1 instance where Rockbox firmware provided more battery life
This has got to be one of the worst arguments I’ve ever seen someone attempt. You don’t even agree with yourself.
Here let me try straightening this out for you:
“Rockbox doesn’t get better battery life, except sometimes, in which case it does.”
So, does this mean that for the e200 I can expect a gapless battery? Discuss.
Saratoga, I like your last post. The quotation is priceless, I must agree.
Out of curiosity, what have you seen regarding battery management parameters, more specifically, the charge percentage display? Does RB simply pull the calculated value, or do you have a new piece of code? The e200 OF never quite made the grade, using a 25 percent gradient (4 steps) unlike the Fuze (10-step).
Out of curiosity, what have you seen regarding battery management parameters, more specifically, the charge percentage display? Does RB simply pull the calculated value, or do you have a new piece of code? The e200 OF never quite made the grade, using a 25 percent gradient (4 steps) unlike the Fuze (10-step).
The rockbox way is pretty stupid. Basically I just took the voltage discharge curve for my specific e200v1 (or maybe someone else’s I can’t remember), picked out the value at dead, 10% … 100%, and put that in a c array. When you ask rockbox for the battery voltage is just draws a line between the nearest multiple of 10% and gives you that value.
In practice this works pretty well since the voltage vs. capacity plot of most lithium poly batteries is pretty similar, but it won’t be exactly right for most people. A smarter way would be to start with that curve and then update it with new ones as the battery discharges, but the dumb way worked well enough that I didn’t bother trying to make it smarter.
