61–70 of 104 posts
Earlier quoted context omitted.
I don't see why this is being downvoted. It's fairly apropos to the subject. And it was the first thing I thought of too when I read the title.
À format that is independent of a specific platform or player has its own merits, besides the scratch your itch part. With a good plugin support an ecosystem to allow interoperability of playlists becomes possible.
Earlier quoted context omitted.
XSPF is a format to enable sharing, AKA universality. It does this by defining a list of metadata fields to be used for resolving each track in the local context of the listener. The UPF "ids" field maps to the XSPF "identifier" field: http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.2 XSPF is not M3U in any way. From the spec: http://xspf.org/xspf-v1.html#rfc.section.3.4 3.4 Content resolver On a surface le…
That sounds like a noble goal, but in a "modern" format designed for the same thing, I'd expect the role of the "identification key" for the files to be played by a format-standardized-algorithm audio fingerprint. Audio fingerprints are the only thing you can really expect to be "portable" between music libraries, when people can put arbitrary things in the ID3, and both combined tracks and compilation albums exist.…
For example a fingerprint might or might not need to draw these distinctions:
- Clean ("Walmart") and dirty (profanity) mixes of the same recording
- Amount of opening and closing silence (often varies across releases)
- Different masterings
- Fidelity of the source recording (e.g. 64K Real Audio vs uncompressed PCM)
In addition, fingerprint developers are constantly improving on their algorithms.
magnet:?dn=Anciients%2FFollowing%20the%20Voice&xt.1=urn:sha1: e577cce68a69735acccd5d8603b3e663f6aa5bc9&xs=nfs://example.com/music/ftv.mp3&x.dur=408.764081632
Earlier quoted context omitted.
That sounds like a noble goal, but in a "modern" format designed for the same thing, I'd expect the role of the "identification key" for the files to be played by a format-standardized-algorithm audio fingerprint. Audio fingerprints are the only thing you can really expect to be "portable" between music libraries, when people can put arbitrary things in the ID3, and both combined tracks and compilation albums exist.…
format-standardized-algorithm audio fingerprint Assuming that's not available on stock Android/iOS/etc a quick hash like md5 should suffice.
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…
Notice that the cardinality is "zero or more."
If I understand correctly, you want to make playlists portable by associating each item with enough metadata to allow identification even when some metadata, such as filepath, changes. Playlist and metadata are separate things, and coupling them is not good from an architectural perspective (redundancy/denormalization). The two can still be related, even in a single file: relational database. (plug: I'm working on ht…
It's definitely a better approach for a library, though, and it's how one would model the data in a database as well.
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.
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…
Earlier quoted context omitted.
format-standardized-algorithm audio fingerprint Assuming that's not available on stock Android/iOS/etc a quick hash like md5 should suffice.
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.
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?
Subtitle: "The Universal Playlist Format"
Analysis: https://xkcd.com/927/