Sorting by bitrate...

in descending(ascending) mode,
96kbps is listed before(after) 256kbps (for example. Same with 128, 320, obviously). Maybe two-digit bitrates should be recorded as 096kbps to solve the problem?

Thank you!

I think the way to solve the problem is actually to just sort it numerically when that column is selected as the sort column. This is usually an option you can give the file list control but Roger will probably pipe in with the specifics. 096 looks cheesy.

The column is actually stored as [fv?][jms?]nnn -- i.e. fixed/variable, joint/mono/stereo, bitrate. There's no leading zero on the bitrate.

In short, it ain't numeric.

This is the sort key, so you'll find that it groups your fixed-rate songs together, etc.

I'll see what I can do about generating a different sort key for that column.

Roger,

I actually I like it! Grouping all the variable bitrate togeter, and than all the mono, is good to me. But again, what I am saying is that when sorted by bitrate in ASCENDING MODE, for example, you have

Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 96Kbps <----
Fixed rate, Stereo, 96Kbps <----

which is clearly wrong.

With a leading zero, you would have, correctly:

Fixed rate, Stereo, 032Kbps <----
Fixed rate, Stereo, 032Kbps <----
Fixed rate, Stereo, 032Kbps <----
Fixed rate, Stereo, 096Kbps <----
Fixed rate, Stereo, 096Kbps <----
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps


So I'd definitely like the leading 0. May look cheesy, but it is correct. Maybe a leading blank space would solve the problem too? In that case, it may look like this:

Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 32Kbps <----
Fixed rate, Stereo, 96Kbps <----
Fixed rate, Stereo, 96Kbps <----
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 128Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 256Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps
Fixed rate, Stereo, 320Kbps

FITNR, without resorting to leading zeroes. Have some faith .

Heh, what I want to know is, why do you even have any files on your player lower than 128?

Books, Tony, books. You know, those papery things. You can get them in audio now, too .

Guh?
sonic paper? it'll never catch on. what do you do? waggle it beside your ear and the word fall off the page into your head?
obsurd

Correect, Roger. Books. Few interviews and other non-music stuff :)

I'll have faith!

Greetings!

Actually, if you remember that problem I had with the VBR having trouble with the timecodes, all of those files seem to be listed by the empeg as 32kbps... I had thought the header was damaged, but never really did anything to try to fix yet (too many files, too little time). Perhaps there is something deeper? Wishful thinking?

We did find a couple of MP3 files that would spoof out the VBR checking in emplode. This has been FITNR.

However, fixing up the data on the player might prove a little more difficult. I'll code something up to reset the VBR data on the player.

In reply to:

---

... I'll code something up to reset the VBR data on the player.

---

Excellent

WOW!!! Thanks!!!

FITNR. You'll be able to right-click on the item and select "Reset metadata". It'll blank the bitrate, duration, offset and samplerate tags. These'll then be rebuilt the next time you download the player database.

NICE solution!

Extremely so!!! It will also allow people to clean up the information from the normalization to.

I will try not to ask the next obvious question...

No it won't. It doesn't touch the normalisation metadata. We'll use a different solution to prevent bogus values in that field.