imagine if we had like a combo of bittorrent and git, for binary content
-
imagine if we had like a combo of bittorrent and git, for binary content
use case: seeding music files but modifying the tags for yourself locally
but the more likely conclusion to be had is that embedded metadata is the real problem
-
imagine if we had like a combo of bittorrent and git, for binary content
use case: seeding music files but modifying the tags for yourself locally
but the more likely conclusion to be had is that embedded metadata is the real problem
i guess re: audio metadata the real question is how much of the metadata is crucial enough to be embedded into the file (id3, vorbis comment, etc)
-
i guess re: audio metadata the real question is how much of the metadata is crucial enough to be embedded into the file (id3, vorbis comment, etc)
also by laws of identity it is no longer the same audio, since even if the actual playable content is identical, the metadata in the container has changed. i'm just wondering if there's a better way or some kinda workaround for this
-
also by laws of identity it is no longer the same audio, since even if the actual playable content is identical, the metadata in the container has changed. i'm just wondering if there's a better way or some kinda workaround for this
possibly on the fly remuxing where the audio itself is stored immutably in content-addressed storage but without metadata? then when it's requested it can be put in a container with metadata sourced externally?
-
possibly on the fly remuxing where the audio itself is stored immutably in content-addressed storage but without metadata? then when it's requested it can be put in a container with metadata sourced externally?
of course the bit i'm interested in is how to generalize this -- music files are just the example here
-
also by laws of identity it is no longer the same audio, since even if the actual playable content is identical, the metadata in the container has changed. i'm just wondering if there's a better way or some kinda workaround for this
@trwnh This is something that vessel can do, in theory. But a music player would have to support it.
Nonetheless, it's what it is intended for: multiplexed bitstreams, chunked up for transport, that can easily be reassembled.
One of the intended use cases was actually not audio, but video with multiple audio streams and e.g. subtitles. An id3 tag would be easier.
-
@trwnh This is something that vessel can do, in theory. But a music player would have to support it.
Nonetheless, it's what it is intended for: multiplexed bitstreams, chunked up for transport, that can easily be reassembled.
One of the intended use cases was actually not audio, but video with multiple audio streams and e.g. subtitles. An id3 tag would be easier.
@jens admittedly this is interesting but what i am really getting at is how to layer metadata from different sources onto the same "content" -- http headers, rdf statements, and so on, what is the atomic unit of content, that kind of thing. the content's embedded metadata might conflict with the external metadata, so which one do you trust? and how do you deal with potentially multiple nested layers of container formats? (plaintext message in an html document in an http message in a text file)
