Database capacity?

I don’t understand …

I have no sansa, I want to buy one but I don’t know if the limit of 8000 songs is because the software in the sansa is limited to 8000 songs or if it is difficult to put 8000 songs in a 32 Go card ? And if with rockbox I can see more than 8000 songs, is the speed of play modified ?

@frenchie23 wrote:

I don’t understand …

 

I have no sansa, I want to buy one but I don’t know if the limit of 8000 songs is because the software in the sansa is limited to 8000 songs or if it is difficult to put 8000 songs in a 32 Go card ? And if with rockbox I can see more than 8000 songs, is the speed of play modified ?

The way the database that tells the player what songs you have is set up, it is limited to 8000 songs. I have far more than 8000 songs in my library. However my music is encoded in such a way that I could not get 8000 songs on a 32 gig anything. If you are using a smaller comperssion then you may be able to reach this number no problem. None of this has anything to do with play speed. The only change you should see is the speed of the database refresh when you update the songs on the player or card. In reality 8000 songs is quite alot and takes some effort to amass so I would say most folks dont have to worry about it. 

The limit on the Clip is 8000 songs.  Actually it’s a good deal less if you have a fairly detailed file structure, longer file names, and longer mp3 tags.

I have an 8GB Fuze with a 32GB card.  All of my music fits on my 32GB card (6708 tracks to be exact).  With the current Clip/Fuze DB structure and my file structure, the Fuze can only see 4771 of them.

If I took all my files out of their folders and simply had a “flat” file structure, I might be able to see more,  If I changed my filenames, (like 1.mp3, 2.mp3, 3.mp3) I could see more.  Both of these are not feasable for me, and it’s likely if I fill my remaining 10GB that are available, it is probable that I will exceed even the “published” limit.

The Fuze+ has over 10000 song limit, (but there are some serious UI issues that plague that device).

Rockbox has a different way it handles DB (far superior) and it refreshes faster and has no such limit.

However Rockbox breaks DRM so you can’t play Rhapsody subscription tracks, only non-DRM tracks.  I still use Rhapsody to when I want specific albums.  Unfortunately, I really like Rhapsody Channels and this is lost when using rockbox (even if you boot it in original firmware mode)

Ok, I think I understand, the limit is a question of size of tags …

There’s no rockbox for the clip zip so I will buy a clip+; too bad for the cover art

If I can’t see all my songs I will just buy a sansa for running with some songs of all my songs

(The solution would must be to charge the songs by groups of 4000 songs and select which group you want to access (with certainly a long refresh tags between) ?)

How to know what are the songs that I can’t see among all the songs in the memory ? Is it invisible from a certain point in alphabetical order?

It’s based on how it is stored on your device.  The database starts at your tree and works down.

For example, I can see immediately where it stopped because the last “folder” shown in folder navigation is “rock albums” and the last band showing is U2.  Therefore, I can see that’s exactly where the database stopped.  Any files located in my file structure past Rock Albums/U2 is invisible.

My entire “seasonal music” or “world music” folder is gone and no songs in those folders are navigatable.

Been wondering this as well–thanks for the explanation!

Yep, personally I was running into trouble at about 3500-4000 songs on my 8GB clip+ with a 16GB micro SDHC in it. The internal database restriction, and some sensitivity to tags, has been my main problem.

So far as DRM content, I have been using Audials to cleanse my songs. It works as good as my 50 year old ears can detect.

I work in db for a living. I’ve touble understanding why Sandisk seems to have this longterm restriction. When memory was expensive, perhaps you could understand. But today memory is cheap, and the market for MP3’s certainly expects more capacity. You’d think it is high time to extend/rewrite that db mgmt support for their players.

@p_opus wrote:

It’s based on how it is stored on your device.  The database starts at your tree and works down.

 

For example, I can see immediately where it stopped because the last “folder” shown in folder navigation is “rock albums” and the last band showing is U2.  Therefore, I can see that’s exactly where the database stopped.  Any files located in my file structure past Rock Albums/U2 is invisible.

 

My entire “seasonal music” or “world music” folder is gone and no songs in those folders are navigatable.

 

 

So would you be able to see more of your collection if you simplified it to just artist folders, like this?

I’ve never bothered with genre sorting for my file structure, whether on my hard drive or my players.

That’s pretty much how my folders are. Folder per artist, then a subfolder per album. Suspect it is the tags and name length, both inherited from the sources, that bites me most. 

…but, the core of the issue is the capacity of the DB structures they are using within. No doubt designed/implemented when memory was more precious and a couple thousand songs on a player was considered bleeding edge.

A cobbled together path could even be something like a huffman conpress/decompress on the tag data internally. Since it is mostly text, that would compress htings pretty nicely with a static compression dictionary. Would mean no change to the underlying DB structures, but would eat some CPU cycles.

I read somewhere(perhaps the Anythingbutipod website?) that embedded album art is likely what is causing some to have only a maximum of around 3500-5000 songs that the player can navigate to.

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 

That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?

Album art doesn’t have to be embedded in the tags though.

@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?

They should be able to…Rockbox devs manage it with the same hardware on the Clip+, Clip, and Fuze, after all.

@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?

http://en.wikipedia.org/wiki/Hard_coded

As in, coded directly into the software and requiring a software update to change (as opposed to having a setting that can be changed without recompiling).

@saratoga wrote:


@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?


http://en.wikipedia.org/wiki/Hard_coded

 

As in, coded directly into the software and requiring a software update to change (as opposed to having a setting that can be changed without recompiling).

 

 

 

Thanks for the link.  I guess I get the meaning, being a non-programmer, between hardcoded and softcoded.  lol

It seems to me that it’s similiar to the difference between v1 and v2 tags.  The v1 tags have a set amount of space to add info into while the v2 tags have the ability to expand with the addition of more info so there’s room for things like lyrics and embedded album art.

@jk98 wrote:

Album art doesn’t have to be embedded in the tags though.

 

 

In regards to this, would a folder.jpg for each album or embedded art take up more of the database?

Rockbox OS is completely file based.  It has a file structure beneath the .rockbox folder on the player, and as such has the freedom to write the DB to the main memory of the device.  As you database grows, the database file it reads from grows.

As long as you have the storage on the device to hold the database file, then you are good.

It looks as if the database on the original Fuze is held within a specified “reserved” space of memory for the firmware.  As a result, there is a limit to the size of the DB.  

The worst part is that the “folder” navigation offered on the player is not true folder navigation and is actually just folder representations of the DB.  

If the folder navigation were simply navigating the file structure, then I could live without the DB.

Thankfully, I found a workaround.  I found that as long as I don’t modify the date in Rockbox, I can overwrite the bootloader and reload the original firmware, transfer files to rhapsody and reload the bootloader.

It adds approximately an extra 2 minutes of time, but allows me to play subscription content.

Not the best, but once I went to Rockbox, I found the original firmware so limiting.  Playlist creation in Rockbox is so easy, I don’t think I could go back.

I hope Rockbox for the zip comes soon, because I will need a replacement player as soon as the internal batteries of my Fuze run out.

@p_opus wrote:

 

I hope Rockbox for the zip comes soon, because I will need a replacement player as soon as the internal batteries of my Fuze run out.

I’ve been using Rockbox on the Zip since last November. :wink: