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

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

#71

Post by StavrosK » Wed, Mar 01, 2017, 9:00 PM UTC

djrogers wrote: post #60

Is the lack of portability really due to the unavailability of a (or yet another) standard format? Seems it's far more related to the music player decisions about what it's playlist format should be...

How so? How will my music player know that "Dark Tranquillity - The Gallery" from Google Music is actually thegallery.mp3 on my local drive?

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

#72

Post by StavrosK » Wed, Mar 01, 2017, 9:02 PM UTC

TTPrograms wrote: post #54

I think a few people have open-sourced various audio fingerprinting algorithms. Perhaps we should standardize around one and enable real UUID for audio files? That seems to be the missing piece for a lot of the novel functionality you're looking to hit. Otherwise you're stuck doing fuzzy pattern matching on metadata, which seems tricky especially considering possible variation in live recording etc.

I don't think the two are different goals. I would very much like standardization around the MBID and AcoustID fingerprint, and my playlist format is just a playlist that uses that. There's no way to use those with a PLS file, for example, even if they were standard and ubiquitous.

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

#73

Post by StavrosK » Wed, Mar 01, 2017, 9:03 PM UTC

zeveb wrote: post #55

hawski wrote: post #9

Are 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.

> 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. And here I was feeling badly for thinking that it'd be better as S-expressions! I wasn't going to post that, but since you already did, here's the same example in the original YAML: --- format: UPL1 name: Favorites id: 2b43009f-d6a6-4f00-8533-09a9a73d8b54 entries: - artist: Anciients title: Fo…

For me, it goes YAML, S-expressions and JSON, in order of prettiness.

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

#74

Post by choward » Wed, Mar 01, 2017, 9:04 PM UTC

rsync wrote: post #67

You know what always, always works ? Copying the actual songs into a directory that becomes "the playlist". It's very inefficient and inelegant but after the 100th car stereo I encountered that couldn't make sense of the most basic m3u file, I just gave up ... my "playlists" are just more copies of the actual songs. Problem solved.

You could combine both solutions and process a playlist file to put copies in a directory whenever you need to actually use the playlist.

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

#75

Post by StavrosK » Wed, Mar 01, 2017, 9:07 PM UTC

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 than when playing it. The problem with multiple file paths is that both have the same weight, so how do you choose?

I guess you'd choose the same way you choose between the formats already, based on whatever is available/found.

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

#76

Post by StavrosK » Wed, Mar 01, 2017, 9:08 PM UTC

rsync wrote: post #67

You know what always, always works ? Copying the actual songs into a directory that becomes "the playlist". It's very inefficient and inelegant but after the 100th car stereo I encountered that couldn't make sense of the most basic m3u file, I just gave up ... my "playlists" are just more copies of the actual songs. Problem solved.

I did that too, and then uploaded those files on Google Music, and now I want to get them back (with the songs I've added since), and... oops.

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

#77

Post by StavrosK » Wed, Mar 01, 2017, 9:10 PM UTC

rout39574 wrote: post #59

StavrosK wrote: post #44

Earlier quoted context omitted.

Thank you, I agree. If I'm going to use JSON, I might as well use ProtoBuf. About MD5, I was worried about a case where a service that serves user-submitted files would be exploited by MD5 collisions, leading users to open files that might exploit decoder bugs to execute code. Far-fetched, I know, but the tradeoff didn't seem worth it. I'm not married to that decision, though.

You can apply a schema to JSON, too. Can you hear us underneath that pile of bike sheds?

Haha, the bikeshedding argument is fair, but not terribly so. It's good to receive feedback of all sorts, and then the designer (me) thinks about it, distills it and makes something that's (hopefully) better than what was there before.

It's only bikeshedding when the decision has to be made by community!

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

#78

Post by StavrosK » Wed, Mar 01, 2017, 9:11 PM UTC

geocar wrote: post #63

Do you know about magnet uri[1]? magnet:?dn=Anciients%2FFollowing%20the%20Voice&xt.1=urn:sha1: e577cce68a69735acccd5d8603b3e663f6aa5bc9&xs=nfs://example.com/music/ftv.mp3&x.dur=408.764081632 [1]: https://en.wikipedia.org/wiki/Magnet_URI_scheme

I do, but it doesn't seem directly applicable to this case. It's similar, but it's better suited to torrents and things like that.

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

#79

Post by StavrosK » Wed, Mar 01, 2017, 9:29 PM UTC

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…

You have swayed me, I have updated the spec, thank you!

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

#80

Post by skookumchuck » Wed, Mar 01, 2017, 9:29 PM UTC

This is not in the least bit surprising. I download financial information from my accounts in the form of .csv files, but have never found any accounting software that will import those files reliably. I finally had to write my own csv parser and then tweak it for each wretched csv data provider to get things to work right.

For example, download credit card transactions as csv. Import into Quicken. Quicken decides that skookumchuck is the payee on all the transactions. Arggh. This is 2017 fer cryin out loud.