91–100 of 104 posts
My own format = https://xkcd.com/927/
However, it has been said, that there are no new stories; they've all be written, and that everything worth inventing has already been invented.
If we actually believed that, there'd be no new books, and stuff like graphene, and CRISPR wouldn't exist.
I say, let everyone re-invent the wheel, one day someone might actually get anti-grav ones working - You never know.
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…
Earlier quoted context omitted.
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.
Earlier 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…
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.
Magnet already does this.
> it's better suited to torrents and things like that.
I don't understand what you mean by this.
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.
The question of hash usage made me think of an alternative approach -- what about some kind of audio perceptual hash? P-hash has support for audio hashes [1] (at least it claims to, but I've never used it). The metadata is useful, sure, but coupling it with the playlist seems like a bit of a strange design choice, if it could be avoided. In my mind, an ideal world would have two databases (or equivalent): one for met…
Example: I just moved all mp3, m4a files to the microSD card on my android phone, keeping names and folders identical, but my playlists are all empty now. Thank you Samsung! grr..
Making a path independent, p-hash independent (but utilizing, if available, or requested) playlist format is what I'd really want. The metadata should always be saved inside the file because metadata get's lost when you change the program. Filling up an sqlite db with all the metadata saved in your audio files would only speed up meta-data management and sync, but remove it's control from you.
Features I think make sense to expect from a perfect music player (without vendor-lock-in), be it run on mobile, web, desktop, cli or as a daemon:
• Path independant, file-name independant (thanks to p-hash) playlist import & export
• Playlist export options for ie. Samsung Music Player, iTunes or whatever crap we're locked-in currently
• Save Metadata incl. rating always inside audio files, because metadata get's lost when you change the program
• Extract Metdata from audio files into a database for speed, management and easier sync into the files
• Audio-Fingerprint may allow detection of: duplicates (hash independant), similars, classify genre and map mood-maps
• Batch-Convert between flac,mp3,ogg,mp4,m4a if user wishes without stupid dialogues. 128Kbit LAME-encoded MP3s don't sound converted to "best quality ogg"..
• Create P-Hashes (or another perceptual hash) initially, when idle, periodically or when requested
Example playlist format:
estelle.mp3, audio-fingerprint, House-Playlist
wu-tang.mp3, audio-fingerprint, PartyNightEarlier quoted context omitted.
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.
Providing enough metadata to recognize the file different ways, is exactly what you're doing. Magnet already does this. > it's better suited to torrents and things like that. I don't understand what you mean by this.
Earlier quoted context omitted.
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?
I was planning on making a cli around some parsing logic and convert/export from various services (wherever I can get an API from).
Earlier quoted context omitted.
Oh, definitely, what's it like?
https://github.com/adamdecaf/univplayfmt I was planning on making a cli around some parsing logic and convert/export from various services (wherever I can get an API from).
Here's the Python converter I'm playing with:
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.