Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Edit FPL files (Read 20684 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Edit FPL files

Hey guys,

Is there any way to edit FPL files if the music files they referred to have been moved to another directory? I tried doing a simple find and replace and changing the paths in the FPL file, but it didn't work. Instead, it gave me an error saying the format was not supported, and the path was doubled. For example, instead of listing the path as "C:\Music\abcd\01.mp3", the path in the error message would be "C:\Music\abcd//Music\abcd\01.mp3" or something along those lines.

What am I missing?

Thanks,

nazgulord.

Edit FPL files

Reply #1
When you edit strings in an FPL file, you must preserve their lengths.

Edit FPL files

Reply #2
It's the old question of not having plain text files in foobar (the config file, the fpl files...)

Nazgulord shows with his example, why text files would be an advantage. Having binary files is an unnecessary barrier imo.


Edit FPL files

Reply #4
Perhaps I miss sth. but why not simply save the fpl playlist in the m3u or m3u8 playlist format and then edit it?

Edit FPL files

Reply #5
It's the old question of not having plain text files in foobar (the config file, the fpl files...)

Nazgulord shows with his example, why text files would be an advantage. Having binary files is an unnecessary barrier imo.


Text files are cumbersome to parse, unnecessarily large and require elaborate escape sequences to code some characters. If I am not mistaken, FPL can store all the tags of each file, including binary fields and fields with new-lines etc which would be awful in a text file.

 

Edit FPL files

Reply #6
If I am not mistaken, FPL can store all the tags of each file, including binary fields and fields with new-lines etc which would be awful in a text file.
If you are not mistaken: True, agreed.

Edit FPL files

Reply #7
Thanks for the replies, guys.

Foosion, I was curious as to what you mean by preserving the lengths of the strings? Does that mean that if the unedited version was 25 characters long, the edited one would also have to be that long?

nazgulord.

Edit FPL files

Reply #8
Thanks for the replies, guys.

Foosion, I was curious as to what you mean by preserving the lengths of the strings? Does that mean that if the unedited version was 25 characters long, the edited one would also have to be that long?

nazgulord.


Correct.

Edit FPL files

Reply #9
If I am not mistaken, FPL can store all the tags of each file, including binary fields and fields with new-lines etc which would be awful in a text file.
If you are not mistaken: True, agreed.

If you need binaries to be stored in text, do a Base64 conversion. Libraries for converting from/to Base64-encoded binaries are freely and widely available.

Besides, if processing a text-based FPL takes 5 seconds, while processing a binary-based FPL takes 2.5 seconds... I would go with text-based all the time. 2.5 seconds is not *that* significant.

Geez.

Without those binary playlists, loading and management of huge playlists would probably be very slow.

Show us some quantitative timing and I'll believe you.

But, even a 100% improvement like I pointed above, is of no significance as the order of time is still seconds.

It will be different if, for instance, processing binary-encoded files takes 1 second and processing text-encoded files takes 3 hours 45 minutes 12 seconds.

Computers are fast enough today that even bubble sort is again popular. It's much easier to code and debug.


Edit FPL files

Reply #11

If I am not mistaken, FPL can store all the tags of each file, including binary fields and fields with new-lines etc which would be awful in a text file.
If you are not mistaken: True, agreed.

If you need binaries to be stored in text, do a Base64 conversion. Libraries for converting from/to Base64-encoded binaries are freely and widely available.

Besides, if processing a text-based FPL takes 5 seconds, while processing a binary-based FPL takes 2.5 seconds... I would go with text-based all the time. 2.5 seconds is not *that* significant.

Geez.

Yeah, sure, startup time is irrelevant, even if most of it is playlist load time bottleneck. I mean, you only reboot once a month anyway, right? And even if you do shut down, you are using hibernate or suspend to disk, right?


Without those binary playlists, loading and management of huge playlists would probably be very slow.

Show us some quantitative timing and I'll believe you.

But, even a 100% improvement like I pointed above, is of no significance as the order of time is still seconds.

It will be different if, for instance, processing binary-encoded files takes 1 second and processing text-encoded files takes 3 hours 45 minutes 12 seconds.


The important point for binary playlists is that you know the length of every field ahead of time, whereas with plaintext, you have to parse until you either hit some end of line marker, or the end of the file. And then you need some way to encode multi-line values. And then there's that base64 for all unknown types.



Computers are fast enough today that even bubble sort is again popular. It's much easier to code and debug.

None of this makes any sense whatsoever. So it's better to code your own grossly inefficient methods when the language you are using has built-in methods (qsort, std::sort, what have you) which are much quicker? Sure, who cares if it's slow, you can't figure out why the built-in methods don't work for you, so why not write your own? The increasingly more powerful systems will cover your ass in the end anyway.

AHHGAGHAGAGAGFJKGKAFASHGAJSDGHSAJDGHASD

Edit FPL files

Reply #12
Yeah, sure, startup time is irrelevant, even if most of it is playlist load time bottleneck. I mean, you only reboot once a month anyway, right? And even if you do shut down, you are using hibernate or suspend to disk, right?

Like I said, if startup with binary file takes 20 seconds, while startup with text file takes 25 seconds, it's not that much different, I can live with that.

The important point for binary playlists is that you know the length of every field ahead of time, whereas with plaintext, you have to parse until you either hit some end of line marker, or the end of the file. And then you need some way to encode multi-line values. And then there's that base64 for all unknown types.

Like I said, how many minutes will it take to parse a plaintext file? And what's wrong with base64? You can also use quoted-printable if you want. Or even HTML-style ampcodes.

Computers are fast enough today that even bubble sort is again popular. It's much easier to code and debug.

None of this makes any sense whatsoever. So it's better to code your own grossly inefficient methods when the language you are using has built-in methods (qsort, std::sort, what have you) which are much quicker? Sure, who cares if it's slow, you can't figure out why the built-in methods don't work for you, so why not write your own? The increasingly more powerful systems will cover your ass in the end anyway.

No, it makes much sense: Binary-encoded thingies makes debugging harder. That is similar to QuickSort vs Bubble Sort. Most Internet protocols (SMTP, POP3, HTTP) use text-encoding. Why? Because it's easier to debug. All you need is a capture of the stream, and without having to specially decode obscure binary codes you can quickly intuit where things start to go awry. It's not the most efficient, but remember that these protocols came from waaaay back when bandwidth are still a mere trickle compared to nowadays.

Now I have nothing against QuickSort; if implemented okay, then I'll use it. If it's buggy or doesn't fit my need, forcing me to write from scratch, I will choose something slower but easier to debug than something faster but hard to debug. Especially if we're talking a difference of mere seconds instead of minutes or hours.

Edit FPL files

Reply #13
Is there any reason not to use an XML list?  It would seem to me that something like ODF, which is essentially an XML file in a compressed archive, would be ideal.  This way, we could actually have the album art with the playlist itself, should we choose, all in 1 file.  Then, editing the file would be as simple as Find --> Replace as well.

Edit FPL files

Reply #14
Like I said, if startup with binary file takes 20 seconds, while startup with text file takes 25 seconds, it's not that much different, I can live with that.
How did you test this?

You may rest assured that the developer tested different ways of implementing a playlist format and his decisions are not only based on his own experience but also on reports he got from testers with much slower hardware where it takes foobar2000 several minutes to start with very big playlists. Besides I don't see the point of this discussion: Everyone can save his playlists in the m3u(8) format if he needs them to be editable. The fpl playlists simply do what they are supposed to do: Providing a flexible and very fast way of storing file information, which can be efficiently parsed by foobar2000.

Edit FPL files

Reply #15

Like I said, if startup with binary file takes 20 seconds, while startup with text file takes 25 seconds, it's not that much different, I can live with that.
How did you test this?

You may rest assured that the developer tested different ways of implementing a playlist format and his decisions are not only based on his own experience but also on reports he got from testers with much slower hardware where it takes foobar2000 several minutes to start with very big playlists. Besides I don't see the point of this discussion: Everyone can save his playlists in the m3u(8) format if he needs them to be editable. The fpl playlists simply do what they are supposed to do: Providing a flexible and very fast way of storing file information, which can be efficiently parsed by foobar2000.

No I did not test this. Note that I wrote 'if', which means that in the hypothetical situation of...

I think a 'much slower' hardware which severely slows down text parsing compared to binary parsing will be unable to decode MP3 and Ogg Vorbis properly.

Yes, saving to a playlist, editing, and importing back is a workaround. The question is: Why binary in the first place.

The API already changes every minor version (i.e. 0.1). If something as sacrilegious as API can even change, why not the format of FPL, CFG, and other configuration files?

Edit FPL files

Reply #16
I don't think that this discussion makes much sense but I'm in the mood for that now.
I think a 'much slower' hardware which severely slows down text parsing compared to binary parsing will be unable to decode MP3 and Ogg Vorbis properly.
Not at all. A PII is perfectly capable of playing back almost every available audio format with foobar2000. We are talking about really big audio collections and playlists with several thousands of files which become quite a bottleneck on such systems.
Yes, saving to a playlist, editing, and importing back is a workaround. The question is: Why binary in the first place.
As I already said, it's about efficiancy. I don't see any good reason why a playlist format has to be manually editable since this is really rarely needed while you start foobar2000 several times a day and want it to start as fast as possible (at least I do).
The API already changes every minor version (i.e. 0.1). If something as sacrilegious as API can even change, why not the format of FPL, CFG, and other configuration files?
Nobody said that the playlist format won't ever change. I just don't think that if it changes it will become a text based format (just some wild speculating from my side).

Edit FPL files

Reply #17
You're all forgetting that 99.9% of users don't care about manually editing FPL files. But everyone wants stuff to be fast. Binary playlists are fast.

The end.

Edit FPL files

Reply #18
Um, what is this? Cats versus dogs?  (j/k)

No I did not test this. Note that I wrote 'if', which means that in the hypothetical situation of...

We have a rule at the forums called TOS #8. We're supposed to be interested in hard facts, not speculation.

You might say that my first post was speculation as well, but I can tell you I have heard before that Windows's registry (which is largely based on plaintext) is slow.

I think a 'much slower' hardware which severely slows down text parsing compared to binary parsing will be unable to decode MP3 and Ogg Vorbis properly.


A Pentium 60 can decode MP3 with DOSAMP or DAMP. I've heard a Pentium 133 can decode Vorbis on Windows 95. I'm pretty sure you'll agree they'll choke on Windows 2000, foobar2000 0.9, with 60000-file libraries and 52 dynamic playlists.

Yes, saving to a playlist, editing, and importing back is a workaround. The question is: Why binary in the first place.


To make use of efficient data structures?

The API already changes every minor version (i.e. 0.1). If something as sacrilegious as API can even change, why not the format of FPL, CFG, and other configuration files?


The API has been stable between minor versions. (0.8.2 to 0.8.3, 0.9 to 0.9.1.) If you mean major versions, it's similar enough for components to be converted to the new API.

The format of the CFG file has been prone to change in the early days. It's much better now. I'd say it's a good thing.

PS. The format of the FPL files has changed before, IIRC. (Or was that the database?)

PPS. But I doubt it will be changed to a text-based one.

Edit FPL files

Reply #19

If I am not mistaken, FPL can store all the tags of each file, including binary fields and fields with new-lines etc which would be awful in a text file.
If you are not mistaken: True, agreed.

If you need binaries to be stored in text, do a Base64 conversion. Libraries for converting from/to Base64-encoded binaries are freely and widely available.


When I said 'awful' I was thinking specifically of Base64.


No I did not test this. Note that I wrote 'if', which means that in the hypothetical situation of...

We have a rule at the forums called TOS #8. We're supposed to be interested in hard facts, not speculation.

You might say that my first post was speculation as well, but I can tell you I have heard before that Windows's registry (which is largely based on plaintext) is slow.


All that is required to load a binary file is reading the file from disk into memory. Done. (Of course a few checks of data integrity and validity should be done along the way).

Reading an equivalent text file means reading the (definately larger, probably a lot larger) file from the disc, running a complicated parser on it, which has to check every character and interpret it.

A binary file is definately faster, and even if the difference is 0.5 seconds for you, its a matter of principle. If developers always did things the easiest simplest way, the time differences would soon add up and the software would be unusably slow.

Edit FPL files

Reply #20
[deleted]

Edit FPL files

Reply #21
Ah, thanks for the insights.
A Pentium 60 can decode MP3 with DOSAMP or DAMP. I've heard a Pentium 133 can decode Vorbis on Windows 95. I'm pretty sure you'll agree they'll choke on Windows 2000, foobar2000 0.9, with 60000-file libraries and 52 dynamic playlists.

I should have added "and 50 static text-based playlists" or something.

Edit FPL files

Reply #22
Quote
We have a rule at the forums called TOS #8. We're supposed to be interested in hard facts, not speculation.
TOS #8 reads:
Quote
8. All members that put forth a statement concerning subjective sound quality, must -- to the best of their ability -- provide objective support for their claims. Acceptable means of support are double blind listening tests (ABX or ABC/HR) demonstrating that the member can discern a difference perceptually, together with a test sample to allow others to reproduce their findings. Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support.
Since I am not talking about sound quality, I believe TOS #8 does not apply here, sorry

Quote
Quote
Yes, saving to a playlist, editing, and importing back is a workaround. The question is: Why binary in the first place.
To make use of efficient data structures?
That's a valid point, yes. The question is, how much more efficient compared to a text file? ... Annnd I believe TrNSZ has answered this question, thanks.

TrNSZ beats me to posting as I was still struggling with mismatched bbcodes, heh

Quote
Quote
The API already changes every minor version (i.e. 0.1). If something as sacrilegious as API can even change, why not the format of FPL, CFG, and other configuration files?


The API has been stable between minor versions. (0.8.2 to 0.8.3, 0.9 to 0.9.1.) If you mean major versions, it's similar enough for components to be converted to the new API.

The format of the CFG file has been prone to change in the early days. It's much better now. I'd say it's a good thing.
Hm. Whatever. IIRC it is a general convention that the first digit is called "major" version, the second digit is called "minor" version, and the third digit is called "subminor" version. But... this is slightly OT so I digress

Quote
Quote
If you need binaries to be stored in text, do a Base64 conversion. Libraries for converting from/to Base64-encoded binaries are freely and widely available.
When I said 'awful' I was thinking specifically of Base64.
What's so awful about Base64?

Quote
All that is required to load a binary file is reading the file from disk into memory. Done. (Of course a few checks of data integrity and validity should be done along the way).

Reading an equivalent text file means reading the (definately larger, probably a lot larger) file from the disc, running a complicated parser on it, which has to check every character and interpret it.
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.

Quote
A binary file is definately faster, and even if the difference is 0.5 seconds for you, its a matter of principle. If developers always did things the easiest simplest way, the time differences would soon add up and the software would be unusably slow.
Simplicity and ease of development/maintenance/use is also a matter of principle to me...

Well, it's been a fun, invigorating discussion  The general consensus of this thread is that the playlist should stay binary as it is. It is of course the prerogative of the developers, and the explanation from TrNSZ is mighty satisfying even to me.

So I will not press my point further.

Gambit, you can sigh with relief now

Peace!

PS: I give up. I don't know what's wrong with this posting that the QuoteBoxes do not show. Sorry.
Gambit: Fixed quotes, IPB ist b0rk again.

Edit FPL files

Reply #23
We have a rule at the forums called TOS #8. We're supposed to be interested in hard facts, not speculation.
TOS #8 reads:
Quote
8. All members that put forth a statement concerning subjective sound quality, must -- to the best of their ability -- provide objective support for their claims. Acceptable means of support are double blind listening tests (ABX or ABC/HR) demonstrating that the member can discern a difference perceptually, together with a test sample to allow others to reproduce their findings. Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support.
Since I am not talking about sound quality, I believe TOS #8 does not apply here, sorry

No, but TOS #8 is the cornerstone of everything that is HA. We're still meant to be interested in objective data, not subjective opinions.

Edit FPL files

Reply #24
No, but TOS #8 is the cornerstone of everything that is HA. We're still meant to be interested in objective data, not subjective opinions.
Well, this is slightly OT but...

Since I am not the one whose making the claim of faster binary processing, the burden is not upon me. I did post, back up there, asking a quantitave measure of speed, which TrNSZ has provided.

I am just hypothesizing that 'if' the improvement is 'as such', 'then' it is acceptable for me. But TrNSZ clarifies that the improvement is 'more than such', so the factuals/objective data has been presented and I concede.

Again, I do not wish to press my point further.

Peace!

PS: <Even_more_OT>What is it with cat avatars, guys??? </Even_more_OT>