Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tired of the non-portability of my playlists, I wrote my own format

universalplaylist.stavros.io

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#81

Post by bostonvaulter2 »

StavrosK wrote: post #36
hammerandtongs wrote: post #35

Earlier 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?

I, on the other hand, loathe editing YAML configuration files because the nesting is so obtuse and difficult to figure out based on limited examples in open source projects. JSON is much easier.

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#82

Post by StavrosK »

I'm currently writing a small converter utility to convert PLS/M3U/etc playlists to UPL and back, and to serve as a reference implementation/proof of concept. If you want to follow development, feel free to star this repo:

https://gitlab.com/universal-playlist/pls2upl

You can also star the repo of the spec website itself:

https://gitlab.com/universal-playlist/universal-playlist-spe...

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#83

Post by derefr »

nosuchthing wrote: post #69
lucasgonze wrote: post #64

Earlier quoted context omitted.

MD5 fails many common use cases and sees differences where there are none. The result will be frequent failures to identify potential matches between different files for the same song.

Ah, yeah if ID3 tags change after the initial md5 ran than it would not be recognized. Good point. The trade off would seem to be if the audio analysis hash needs to scrape though a huge playlist and it's running on a slow arm processor than it would be impractical and no one would want to use it. MD5 might not be ideal, but how often do people edit their files after making one of these playlists?

This design assumes a bit of standing infrastructure around it: namely, that you have a "music library manager" program, all your music is in it, and it fingerprints tracks on import and keeps a fingerprint-keyed index.

If that's true, then nothing has to happen on export. You just dump the hashes you already know.

And then, when you try to load someone else's playlist, all you're doing is a bunch of hash-table lookups against the index you already have, to see if you have tracks with matching fingerprints.

(And the initial generation can also be made cheaper, if online music stores also adopt the fingerprint format, such that tracks you buy come with their fingerprints pre-calculated and embedded into the ID3 metadata. Then you can just dump those straight into your index on import.)

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#84

Post by adamdecaf »

StavrosK wrote: post #82

I'm currently writing a small converter utility to convert PLS/M3U/etc playlists to UPL and back, and to serve as a reference implementation/proof of concept. If you want to follow development, feel free to star this repo: https://gitlab.com/universal-playlist/pls2upl You can also star the repo of the spec website itself: https://gitlab.com/universal-playlist/universal-playlist-spe...

I was starting to write one too! I've got a couple of commits I can share if you're interested.

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#85

Post by StavrosK »

derefr wrote: post #83
nosuchthing wrote: post #69

Earlier quoted context omitted.

Ah, yeah if ID3 tags change after the initial md5 ran than it would not be recognized. Good point. The trade off would seem to be if the audio analysis hash needs to scrape though a huge playlist and it's running on a slow arm processor than it would be impractical and no one would want to use it. MD5 might not be ideal, but how often do people edit their files after making one of these playlists?

This design assumes a bit of standing infrastructure around it: namely, that you have a "music library manager" program, all your music is in it, and it fingerprints tracks on import and keeps a fingerprint-keyed index. If that's true, then nothing has to happen on export . You just dump the hashes you already know. And then, when you try to load someone else's playlist, all you're doing is a bunch of hash-table look…

Spot on on everything, except the "assumes" part. I'm writing a utility that will convert to/from PLS/UPL without the infrastructure (granted, it will do it on the fly, and it will require some tags to be in the files):

https://gitlab.com/universal-playlist/pls2upl/

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#86

Post by zeveb »

StavrosK wrote: post #75
zeveb wrote: post #56

I think rather than having a single URI attribute and other identifiers, you ought to allow multiple URIs, and make all other identifiers just be URIs (since, after all, a URI is a Uniform Resource Identifier, and music files are resources). You can represent hashes using the named-information URI scheme ( https://tools.ietf.org/html/rfc6920 ), e.g. ni:///sha-256;u88lYWn4xAlto-6Bs79KHHYDAu28US71ui5Be6C-ZVw. Your file…

This isn't too different from the current format, except the URI method is pushing the type into the URI, rather than into the name of the key. I do wonder about what you said, though: Would it be useful to be able to specify two different file paths or URIs for the same item? I'm leaning towards no, because, when clicking on an entry, you want it to start playing, so the choice is made when adding the file, rather t…

> This isn't too different from the current format, except the URI method is pushing the type into the URI, rather than into the name of the key.

Yup, which I think is good, since URI schemes already exist for many identifiers, and more can be added.

> Would it be useful to be able to specify two different file paths or URIs for the same item?

I think so. Maybe one is one removable medium and the other is on another.

> The problem with multiple file paths is that both have the same weight, so how do you choose?

If they have equal weight, does it matter which you choose?

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#87

Post by joshka »

One of the key things I've looked for in a playlist format for many years is the ability to handle files that contain multiple tracks. My main example of this is continuous DJ mixes that are a single file. You might also see this in live recordings of performances where the interaction with the crowd between each song.

These single file media items generally have 1 or more Album Artists (e.g. the DJ) with each track in the performance blending into the next. Each track may have an associated Artist and Track name. Conventionally the best approach to solving these is to use a Cue sheet and a plugin for whatever media player that can load these simultaneously. Alternatively (though rarely) a container format that supports chapters / sub streams (e.g. mka) can be used.

I don't see a secondary (CUE sheet) format as being the right solution to this problem. To me a playlist and a list of tracks played in a performance are kind of the same thing and should be handled by the playlist.

My proposed extension to the UPL format is to allow each playlist entry to specify a part of the identified file. Now there's two possible ways of doing this:

1. Sub items under the entry (e.g. chapters)

2. Each entry specifies a start and end time (or duration)

You mention at [1] that this format is about display, I feel this fits within that idea by being something that is otherwise difficult to display using any other available info (ID3 tags etc.)

[1]: https://gitlab.com/universal-playlist/universal-playlist-spe...

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#88

Post by StavrosK »

adamdecaf wrote: post #84
StavrosK wrote: post #82

I'm currently writing a small converter utility to convert PLS/M3U/etc playlists to UPL and back, and to serve as a reference implementation/proof of concept. If you want to follow development, feel free to star this repo: https://gitlab.com/universal-playlist/pls2upl You can also star the repo of the spec website itself: https://gitlab.com/universal-playlist/universal-playlist-spe...

I was starting to write one too! I've got a couple of commits I can share if you're interested.

Oh, definitely, what's it like?

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#89

Post by StavrosK »

zeveb wrote: post #86
StavrosK wrote: post #75

Earlier quoted context omitted.

This isn't too different from the current format, except the URI method is pushing the type into the URI, rather than into the name of the key. I do wonder about what you said, though: Would it be useful to be able to specify two different file paths or URIs for the same item? I'm leaning towards no, because, when clicking on an entry, you want it to start playing, so the choice is made when adding the file, rather t…

> This isn't too different from the current format, except the URI method is pushing the type into the URI, rather than into the name of the key. Yup, which I think is good, since URI schemes already exist for many identifiers, and more can be added. > Would it be useful to be able to specify two different file paths or URIs for the same item? I think so. Maybe one is one removable medium and the other is on another.…

You're right, I have updated the spec to make each item a list. Since the URIs can be anything (including files), this is pretty much equivalent to your proposal.

Re: Show HN: Tired of the non-portability of my playlists, I wrote my own format

#90

Post by jason_s »

joshka wrote: post #87

One of the key things I've looked for in a playlist format for many years is the ability to handle files that contain multiple tracks. My main example of this is continuous DJ mixes that are a single file. You might also see this in live recordings of performances where the interaction with the crowd between each song. These single file media items generally have 1 or more Album Artists (e.g. the DJ) with each track…

+1, I was going to suggest the same thing. Or at least the ability to note multiple files which are supposed to be chained together in order. It pisses me off when Shuffle doesn't handle these properly:

- Pink Floyd, Brain Damage followed by Eclipse

- Queen, We Will Rock You followed by We Are the Champions

- Yes, Long Distance Runaround followed by The Fish (Schindleria Praematurus)

- the different movements of Beethoven's Fifth Symphony

Post reply on HN