Skip to main content
Topic: Edit FPL files (Read 17520 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Edit FPL files

Reply #25
[deleted]

Edit FPL files

Reply #26
[deleted]

Edit FPL files

Reply #27
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":
Code: [Select]
(%:~/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).

Edit FPL files

Reply #28
[deleted]

Edit FPL files

Reply #29
Quote
Redundant data is encoded similarly to run-length encoding, to avoid redundant IO. I don't recall when Peter implemented this. There is also experimentation underway to use compression to increase speed, since the process is mostly IO bound now.
Ahhh... okay, that's really informative. Thanks for elaborating.

But isn't compressed data more prone to bit-errors? How do you recover from errors?

(Again, not pressing my point here. I'm really curious and want to learn about this )

Edit FPL files

Reply #30
[deleted]

Edit FPL files

Reply #31
[deleted]

Edit FPL files

Reply #32
Hm, you have a point there. Bit-errors in compressed data usually results in complete corruption of data.

But OTOH, bit-errors in uncompressed data means some data can still be salvaged. Error (hopefully) gets detected during usage of data, or each entry can be protected by simple CRC-32.

Anyways, <OT>thanks for the links. I am only vaguely aware of Combsort and it rivals Quicksort in performance (according to wikipedia there) while a lot simpler... I'll test this algorithm at home extensively.</OT>

Edit FPL files

Reply #33
[deleted]

Edit FPL files

Reply #34
Also, when it comes to teaching sorting algorithms, see http://www.cs.vu.nl/~dick/gnomesort.html for something simple, but not too effective for teaching.
LOL... thanks but no, thanks. It's enough for the students to learn one inefficient sorting algorithm. And now I need to integrate CombSort into the oh-so-limited timeslots given to me for teaching



Edit FPL files

Reply #37
I still don't really understand why this discussion even came up, as you can always save to m3u...
The thread starter IIRC was talking about editing a playlist. For instance you might want to search/replace in foobars database.fpl (instead of doing a rescan media library)

Edit FPL files

Reply #38
Quote
Redundant data is encoded similarly to run-length encoding, to avoid redundant IO. I don't recall when Peter implemented this. There is also experimentation underway to use compression to increase speed, since the process is mostly IO bound now.
Ahhh... okay, that's really informative. Thanks for elaborating.

But isn't compressed data more prone to bit-errors? How do you recover from errors?

(Again, not pressing my point here. I'm really curious and want to learn about this  )


That's not really foobar's problem, you won't get bit errors on a modern system, the filesystem/network protocols/however you got the data should detect any corruption, and fail completely when they do so (if it is not possible to succesfully re-read/resend the data)

 
SimplePortal 1.0.0 RC1 © 2008-2019