rw-r-r- 1 mike mike 181K 21:40 _padding_file_0_if you see this file, please update to BitComet 0.85 or above_
What the hell? Now I see why everybody hates BitComet. Just email or FTP or something each one to me. Speed and capacity is good, Bandwidth per month is limited, but I doubt that many people want these files.
Would you host them as FLAC? I also could provide them as Ogg Vorbis or MP3 if you like, which I would encode directly from a 24 bit master then, ie. Have an example in FLAC format (4'20", 27.0 MB): Nothing beefed up, of course, as the whole point is giving the pure sound of the original tracks to people who don't own one of those Roland devices. It is mastered in Adobe Audition for CD quality. They are certainly better than the DACs on those old Roland devices, thus more than adequate. I recorded the MIDI files (that link from this thread) through a M-Audio Delta-44, which has 24 bit ADCs providing a decent quality. And definitely better noise ratio than a SCC1. It is basically a SC-55 in a different housing and more knobs and sliders. I got myself a Roland Sound Canvas SC-155. This would also allow verifying torrent data downloaded with a padding-aware client.Now, I have to dig up this thread, as I have something for your ears.
Any missing files that fit the heuristic should be tried with zero-filled files when "Verify local data" is run before actually reporting them as missing. This is the point where an option might be in order ("Remove padding files from downloads") for everything else I wouldn't see any reason to add user configuration. Files that fit the padding heuristic and are zero-filled could be removed when the download is completed (or never be put to disk in the first place). Files filled with zeroes can be stored as sparse files where the file system supports it, thus not taking up actual disk space. (There's some room for optimization in evicting the zeroed blocks first, but it's probably corner case enough not to matter). In the exotic case that a file is named like padding but isn't actually, verification will fail, and those blocks need to be actually downloaded. When fetching pieces that contain a padding file, treat all blocks that are part of a padding file as pre-populated with zeros. Add a heuristic of what is likely to be a padding file (naming appears to follow the ^\.?_padding.*$ regular expression). Not stressing the swarm with zero block transfers:. There's three aspects to it that could largely be addressed individually: Just ignoring them will not give all the benefits a padding file has (which is to allow deduplication over different torrents / torrent versions with some identical files without having to actually transfer the padding over the wire), and would require user intervention that I'd expect rarely to be accurate in practice.
0 kommentar(er)
