I've never had a problem with my Winamp playlists going from one PC to another. I just double click them and the music plays.
And if you mive the library you do a search-replace on the path :)
Show HN: Tired of the non-portability of my playlists, I wrote my own format
31–40 of 104 posts
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#32I'm a little confused why '3.3.1. entries' is a sub-bullet of '3.3. id'. Perhaps it's just a typo?
Yes, the entry names are automatically done by a hacky module I wrote, I'll fix it, thank you.
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#33Earlier quoted context omitted.
Not yet, but great idea, I've added it, thank you! YAML is a superset of JSON, so the file can look like JSON if you want, although that's not mandatory. I don't think there are many languages that don't support YAML these days, and one of my goals was to make the format not-entirely-unreadable by humans.
> I don't think there are many languages that don't support YAML these days YAML is a big and complex format though, libyaml's header is bigger than the entirety of libtoml. I think hand-editable playlists are a good idea, just not a fan of yaml.
Hm, yeah, that's true, and I see your point. Right now I think the benefits outweigh the costs, but I'll definitely think about this (for embedded players, etc).
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#34Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#35Are relative paths supported? Probably in this day and age it would have better chance at adoption if it would be a JSON file. It's just network effects.
Not yet, but great idea, I've added it, thank you! YAML is a superset of JSON, so the file can look like JSON if you want, although that's not mandatory. I don't think there are many languages that don't support YAML these days, and one of my goals was to make the format not-entirely-unreadable by humans.
In practice there aren't many languages that support anything more than yaml 1.0 from my last look a few years ago.
Ie yaml isn't nearly as supported as it looks once you start actually trying to use it between languages with anything more than 1.0 as most of the purported library support seemed to be roughly 2009 abandonware.
Yaml also precludes easy https://www.sqlite.org/json1.html and postgresql jsonb etc. Not to mention trivial js consumption of the file.
Superset or not, Yaml automagically introduces bugs to and from json through the magic powers of more lines of code involved.
Most projects would have a hard time not having a json library these days? I've not done a survey of music apps though.
In practice, as someone that has been vim/emacs for a few decades I'd put a low priority on yaml vs json text editability. They are about the same for changing a few characters and I'd probably use orgmode+ python to do anything non-trivial but not full program(and probably drive the transform via json data from somewhere...).
In 2017 yaml doesn't seem tasteful for this format.
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#36Earlier quoted context omitted.
Not yet, but great idea, I've added it, thank you! YAML is a superset of JSON, so the file can look like JSON if you want, although that's not mandatory. I don't think there are many languages that don't support YAML these days, and one of my goals was to make the format not-entirely-unreadable by humans.
In practice there aren't many languages that support anything more than yaml 1.0 from my last look a few years ago. Ie yaml isn't nearly as supported as it looks once you start actually trying to use it between languages with anything more than 1.0 as most of the purported library support seemed to be roughly 2009 abandonware. Yaml also precludes easy https://www.sqlite.org/json1.html and postgresql jsonb etc. Not to…
Really? For me, editing JSON is always a chore, because you have to match the multiple nested brackets, otherwise your whole file is invalid and you get to have fun finding out what you did wrong. YAML, in comparison, can be visually inspected quickly.
However, with all the apprehension in the thread, I'm rethinking this decision. Maybe TOML would be better?
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#37Earlier quoted context omitted.
> I don't think there are many languages that don't support YAML these days YAML is a big and complex format though, libyaml's header is bigger than the entirety of libtoml. I think hand-editable playlists are a good idea, just not a fan of yaml.
Hm, yeah, that's true, and I see your point. Right now I think the benefits outweigh the costs, but I'll definitely think about this (for embedded players, etc).
Another consideration is that yaml's sheer complexity creates more possibilities for interoperability issues. No two parsers for JSON behave identically, let alone for something as large as yaml.
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#38Earlier quoted context omitted.
In practice there aren't many languages that support anything more than yaml 1.0 from my last look a few years ago. Ie yaml isn't nearly as supported as it looks once you start actually trying to use it between languages with anything more than 1.0 as most of the purported library support seemed to be roughly 2009 abandonware. Yaml also precludes easy https://www.sqlite.org/json1.html and postgresql jsonb etc. Not to…
Really? For me, editing JSON is always a chore, because you have to match the multiple nested brackets, otherwise your whole file is invalid and you get to have fun finding out what you did wrong. YAML, in comparison, can be visually inspected quickly. However, with all the apprehension in the thread, I'm rethinking this decision. Maybe TOML would be better?
Pretty printed json isn't too bad, but I intentionally never bulk edit it. This format shouldn't end up heavily nested anyway?
Toml is nice for simple configs/Cargo.toml but I think everything I said basically applies to it as well. Toml has recent work on it in 2017 for some (but not broad) library support but what does it look like in 2024?
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#39Directories of numbered symlinks, my friends.
Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format
#40This is such a good idea. If nothing else, third party tools that people make to transfer playlists between platforms could standardize on this and, in doing so, would reduce duplicated efforts. After trying (and being dissatisfied with) EVERY music service, I'm currently trying to consolidate back to Apple Music. Manually. It's awful.
Since this is coming along rather okay, I think I will write a converter this weekend. I aim to have it accept an M3U/PLS playlist and the corresponding files and write out a UPL.
The opposite step would be a bit harder, I'd have to index all music files in a library and convert the UPL to PLS, which might be too much work for a simple tool, but I'll see if it can be done quickly and dirtily. That would be a nice idea, `upl2pls -i favorites.upl -o favorites.pls` and your favorite player is ready to play the files.