3 ms·
Seems like this would corrupt the file. There are plenty of metadata fields you could just put some crap in (or just transpose letters in an existing string so
by nick238 2y ago
Seems like this would corrupt the file. There are plenty of metadata fields you could just put some crap in (or just transpose letters in an existing string so you don't need to change any length markers.
- ricktdotorg 2y agoi've never had any problems with playback using the major vid players on Linux with files i may or may not have used this trick on.
- nomel 2y agoI would really hope they would ignore the metadata, when computing the hash, for this very reason. Properly tagging films you download isn't exactly rare.
- toast0 2y agoMost media files are likely to tolerate random garbage tacked on to the end of the file. ID3v1 tags are essential proof of that; 128 bytes of garbage at the end that didn't cause any trouble with playback.
- wongarsu 2y agoThat depends on the container format, and with some container formats on the parser. Any container format designed to be streamable would by definition survive corruption at the end. Provided the player doesn't get too upset if any metadata at the end is corrupted, but e.g. VLC handles such things quite well
- delecti 2y agoAs a fun example of "depends on the container format", one trick people used to use for sharing files on image boards (4chan and the like) was to concatenate a rar file and jpg file. I don't remember which order it was, but one of the two used a header (read start to end), and the other used a "footer" (read end to start), so you could use it either way depending on what you opened it as. I still have a handful of files which are books in PDF format in a RAR file, and simultaneously the book's cover as a jpg.
- cowboylowrez 2y agoI remember this too but with jpgs and zips, if I remember, jpgs go first as zips have the metadata at the end of the file (to the best of my knowledge, corrections welcome).