Base64-encoded data exceeds the original in length by the ratio 4:3, and typically appears to consist of seemingly random characters. As newlines, represented by a CR+LF pair, are inserted in the encoded data every 76 characters, the actual length of the encoded data is approximately 137% of the original text data. Remember that FPL is already only a fraction of the size of the text data. Base64 is an extremely poor choice. I can make a safe assumption that Base64 format would cause my playlists (about 50MB of FPL files) to grow in size by at least three-fold.
Well it's only 'seemingly' random. 137% does not sound too bad; but how can the growth is three-fold?
The question is not to press my point, just curious. This is related to the next one.
A lot larger? I think not. The most significant element of a playlist is already text-based, i.e. the full path of the media file pointed by the list. Growth will result from integer/real values which have to be either alphanumeric-encoded or Base64 encoded. And a parser need not be complicated, if the text-based file is designed properly.
Wrong, you are very unfamaliar with FPL files, and this is obvious. A simple test for you - take only a medium sized playlist of, say, 20,000 entries and save it and look at the size of the resulting FPL file. Then copy those 20,000 entries and paste them into the playlist again four times, so you have the playlist duplicated for a total of 80,000 entries, and then look at the size of the FPL again.
Simply stated, an FPL does not contain redundant data across entries. Your assumptions here are incorrect. There are many other optimizations as well that exist to reduce IO time. FPL writing/reading is a unique process in that it is optimized so that it is currently mostly bound to disk IO speeds, where all other playlist types on all other players are not.
You mean you actually did some compression in the FPL?
Now this intrigues me; can you elaborate?
BTW, I just added "everything" to iTunes.... and.... "lol":
(%:~/Music/iTunes)- ls -lh *Library*
-rw-r--r-- 1 trn trn 916M Aug 26 01:15 iTunes Library
-rw-r--r-- 1 trn trn 913M Aug 26 01:22 iTunes Music Library.xml
1829MB? lol.
Edit: This is why a) I only use about 90 large playlists in foobar2000, and b) why the Media Library was invented and happens to be much more efficient than the library used in iTunes (or Winamp).
Makes me glad I don't use iTunes
Computers are fast enough today that even bubble sort is again popular. It's much easier to code and debug.
Sorry to pick on you again, pepoluan, but what are you smoking?! I just read this again and never laughed so hard. Who would implement a bubble sort over a quick sort?
Performance-wise, I'd choose quicksort any day.
a) A fast selection sort can be implemented in ANSI C in less than 7 lines of code by anyone having read an introductory C book and with zero prior computer experience. Wikipedia's entry for "selection sort" provides a C implementation with comments in 12 lines.
Can you give me the link? Anyways, Quicksort is actually exchange sort not selection sort. Which is quite interesting, as plain exchange sort is slower than selection sort, while optimized exchange sort (e.g. Quicksort) is faster than optimized selection sort (e.g. Shellsort).
b) Why bother implemeting a bubble sort at all? Quicksorts have been standard in computing since the early 1960's and are part of ANSI C. qsort(), etc.
Yup, that's the point. If it's been implemented correctly, I don't want to reinvent the wheel.
c) The only people who write bubble sort algorithms are middle school or high school students learning programming. A bubble sort is somewhat more complex to understand than a selection sort and is half the speed.
Yup, that's right. But it is simpler than Quicksort still, and it does not rely on recursion.
I really wonder where you get your information, or if you make it up. Again, I'm not trying to offend, but just pointing out how absolutely absurd this is.
Nope, I'm not making this up. It was the result of a long discussion on teaching computer sciences at my university (I taught data communications 1 and nearly all networking-related stuffs there).
Topic: Edit FPL files (Read 20751 times)
previous topic - next topic