Is there a torrent client that can parse the header of mkv files so I'm able to download only the subtitles from a frickhuge video file?
 Nothing Ever Happens Shirt $21.68 |
 UFOs Are A Psyop Shirt $21.68 |
Nothing Ever Happens Shirt $21.68 |
Is there a torrent client that can parse the header of mkv files so I'm able to download only the subtitles from a frickhuge video file?
Okay, after getting a first piece supposing I parse the mkv header myself, how do I instruct Qbitorrent to download only the byte offsets I tell it to
you dont, either patch the client to be able to do this, or, the easier method would be to automate for these pieces to be downloaded and then stop the torrent, manually find the required data and extract it before removing the torrent
>manually find the required data
i meant manually write code to automate finding the required data...
try biglybt it has some advanced features like that
No, if its on nyaa it's probably on AnimeTosho though which has the subtitles as attachments usually.
There should be, or only the audio tracks you want. Or only the part of a zip file you need. Get coding.
THATS THE GREAT THING ABOUT OPEN SOURCE SOFTWARE ANON!!!!!!!!!!!!!!!!!!!!!!!!!
It's mind boggling that no one has attempted the needful yet, with how commonly I see people complaining about .zip files in torrents. It's surely possible to only get the piece having the index of the zip file, and then only download pieces that correspond to files I was able to list from the index
the bigger needful is seeding everything kiddo, so no one who torrents a lot would give a shit about this feature
if you're a cuck
>you're a cuck if you help share any and all data with your fellow white people for no cost at all
smartest ranjeet, kek
SIR SIR YOU DONT UNDERSTAND YOU MUST SNEED SIR-
YOU HAVE TO
>
>HAVE TO
>moving the goalpost
concession accepted, cheers.
Shit, I didn't know ticking off a folder was bad for the swarm, surely this harmful feature is getting retracted in the next version of bitorrent? Shame Bitorrent v2 is just getting implemented in clients, it took them this long, I can't imagine how the swarm is going to survive if people can tick off data/dolphin/sex.mp4 from downloads!
>It's surely possible to only get the piece having the index of the zip file
oh anon you have no idea. You do know the zip standard doesn't actually specify where the index is, right?
it may be convenient for individual but on a greater scale making this harder benefits swarm as it doesn't have to feed a leach that wants 5 specific chunks
Subtitle data is mixed with the audio and video data over the entire file, so the header isn't enough.
This is the kind of response I wanted. I don't think that's quite right though. MKV files' header has a "SEEKHEAD" element that lists the position of all the tracks, to not have to search the entire file to find them.
Formats like MKV were built for streaming (although MKV itself is not used on the web, WEBM, which is based on MKV is) where the tracks are need to be able to accessed without spending the bandwidth of the entire file. I want to do the same, track selection in torrents.
4shit discarded my detailed response so:
>cues is the seek index but it doesn't have to contain pointers to all packets
>mkv files written with newer software may or may not have cue entries for every subtitle packet
>generally you have to read the entire cluster section to see all packets
>use animetosho which provides extracted subs downloads
I'm not talking about the Cues element, SeekHead is something else.
>generally you have to read the entire cluster section to see all packets
I must acknowledge that SeekHead isn't quite specific enough to list all the Clusters (containing e.g. video/audio/subtitle data) but there's probably an optimized way to walk the Clusters listing
SeekHead is just something that tells you whether there are more header elements at the end of the file.
Nope, SeekHead tells you the position of the eight elements seen in this screenshot:
. It tells you the position where Clusters begin to be listed.
https://matroska.org/technical/diagram.html
I want to call attention that I don't what I'm talking about. I just skimmed the link above. If I was an expert I wouldn't have made the question.
Technically that's true, in practice it's more complicated and really just tells you where to seek at the end of the file to get more headers. It's useless for the thing you're trying to do.
Can you link the part of the spec (or mkvtoolnix documentation?) that says that, I would like to understand it myself
No. But SeekHead will contain only 1 cluster at most (the first one). Cues point to more clusters, based on the video time, but not every cluster needs a cue entry.
But each Cluster must list its length, which we can probably sum to cluster's 1 byte position to get near cluster 2's byte position
You have to read the header of the cluster element. Except in the are cases when clusters have their length field not set, but I don't remember the details.
Why would you do this instead of just downloading the appropriate .srt from opensubtitles?
Not everything is on opensubtitles, mongoloid
So what video are you trying to get the subtitles from?
Thats not how mkv susbtitles work.
Why not just go on opensubs.com or whatever to download the subs?
>mkv files in 2024
is there a term for people that haven't learned a single new tech thing in 10 years but still consider themselves tech literate
kys
mkv is objectively the best video container ever