It turns out that the Fuze’s database creation (“refresh”) time and song-to-song access time (the time to move from one song to another after the database is built) are very sensitive to the size of the biggest directory of the library. If you are having problems with long database rebuild times or multi-second song-to-song transitions, the size of your directories may be the problem. There are other threads dealing with other causes of these problems and, for completeness, I reference them here:
To test the sensitivity of the Fuze to library directory size, I took a library of 1250 songs (MP3, 3.2 GB) and divided it into different directory configurations. I then measured the time it took to rebuild the database (what the Fuze calls “Refreshing your media”) and the time it took to move from song to song with the “right” arrow button (the length of time it took the song number to change, to eliminate measuring any silence @ the beginning of a song). The library ID tags consisted solely of artist, title, & genre in ID3V2.3 ISO format (created by and verified with MP3Tag). The tests were performed in external memory (32GB microSD card). The Fuze was in MSC mode. I didn’t reformat between each test – I just edited the directory structure directly on the Fuze with Windows Explorer. Here are the raw results:
directories #songs per directory Rebuild time Song-to-song time (sec)
--------------- ------------------------ --------------- ----------------------------
25 50 1:57 1
12.5 100 2:20 1
6+ 200 2:47 1
4+ 300 3:11 1
3+ 400 3:38 1
2+ 500 3:59 1.5
2+ 600 4:28 2
2+ 700,500 4:50 2
2+ 800,400 5:02 2
2+ 1000,200 5:58 2.5
1 1250 7:20 3
From the above data, it appears that the Fuze’s database build time starts to measurably climb with as little as 100 songs in a directory. The song access time doesn’t start to measurably increase until there are about 500 songs in a directory. I can understand how the directory size might affect database build time (not as much as I observed, however), but I do not understand how it affects access time afterwards. To me, once the database is built, a pointer to the starting cluster for each song should have been extracted from its directory entry and stored in the Fuze database. From then on, the directory structure should not be needed. I am missing something, based on my observations. Regardless, it is what it is, and there will be no Fuze firmware updates in the future; we must live with what we have.
My flat library structure was what was causing my long database rebuild and song access times. I was not about to change it on my PC since it has served me well for many years. My only question then was how to segment my library on the Fuze to achieve satisfactory build and access times. I did one last set of tests with directory sizes of 50 and 100 in external memory, formatted with SDFormat before each test. The results were:
directories #songs per directory Rebuild time Song-to-song time (sec)
--------------- ------------------------ --------------- ----------------------------
25 50 1:55 1
12.5 100 2:06 1
Rebuild time is 9.5% slower with 100 songs in a directory compared to 50 songs in a directory. Access time difference is not measurable. I decided to go with 100 songs per directory for my full library (3500 songs, 9.4 GB) and accept the 9.5% penalty.
I created 35 artificial subdirectories on the microSD card and populated each with 100 songs from my library. Refresh time for the full library was 6:28. Access time was still 1 second. Success! If I had gone with 50 songs per directory, my build time would probably have been around 5:55 (I did not actually test this – I was sick of creating & testing directories by now). I decided 30 seconds per build was a small price to pay to be able to work in chunks of 100.
Finally, some comments on using MP3Tag which I haven’t seen documented. Spend the time to learn its options via Tools->Options->Tags. Then, do the following:
- Remove ALL tags from your whole library
- Remove all extended tags you don’t need from your library (via View->ExtendedTags or the ExtendedTags target in the right mouse button’s context menu)
- Create ID3V2.3 ISO tags for your whole library
- Turn on viewing of all possible tag columns via View->CustomizeColumns
- Verify that you don’t have any superfluous tags by sorting each column in both ascending and descending order. See if any weird values show up. Edit appropriately.
- This should insure that you have 100% pure ID3V2.3 tags, and only the ones you want.
I hope this information helps people experiencing the same problem I was. Without the Forum, I would have returned my Fuze by now.
