Derive torrent identities and MIDI timelines from the original bytes
Why torrent identity must use the original info bytes, and why a MIDI second query needs every tempo interval. Distinguish useful local reports from stronger claims.
An identity field is not a generic file hash
A metainfo mismatch can happen even when a parser successfully lists the files. The task is to reproduce the identity your torrent client shows. The input to that calculation is the original bencoded info value, not the whole container and not the pieces field alone.
A decode/re-encode round trip can change noncanonical input. Neatbo therefore validates the original encoding and hashes its exact info byte span. The report makes the boundaries available for an independent hash calculation. This produces a repeatable metainfo identity, without claiming that the payload exists or matches its declared hashes.
| Question | Evidence used | Remaining check |
|---|---|---|
| Metainfo identity | Original info byte-span SHA-1 | Compare the client identity |
| Declared file layout | Lengths, concatenated offsets and piece bounds | Examine file contents separately |
| Notes near a second | Full tempo integration and explicit note-state policy | Compare producer events/policy |
A file boundary need not be a piece boundary
In the small example, a three-byte file and a five-byte file are concatenated under four-byte pieces. Both touch piece 0. Treating each file as starting a new piece would produce an incorrect layout even though its individual length looked plausible.
Declared offsets and inclusive piece ranges help explain what a client is showing. An empty file has no piece interval. Actual content verification would need the relevant bytes from all files sharing a piece; this release reads metainfo only and does not imply that stronger verification.
A second is an accumulated tempo conversion
The MIDI example crosses a tempo change: 480 ticks take 0.5 seconds first, while the next 480 take 1 second. A constant multiplier would place tick 960 at the wrong time. A query for notes near a second needs the complete preceding tempo history.
After integration, interval overlap answers which key-release spans intersect [start, end). It is different from selecting only note-on events inside that interval. Keeping every note once with a selected flag lets a receiver compare matched and unmatched notes without losing the context.
Event policy belongs beside the result
MIDI event streams can contain repeated openings of a pitch, unmatched closing events or notes left open at a track end. Neatbo uses a stated FIFO key-release policy and explicit warnings. Sustaining pedal events are preserved but do not change those spans.
A tempo conflict across tracks has no unambiguous global timeline under this policy, so the tool rejects it. A different reader may apply a different overlap or pedal policy; compare the source events and policy before interpreting a difference as corruption.
Use complete reports for downstream checks
Preview and copy are intentionally bounded. Save complete JSON for original identity boundaries, every torrent hash, MIDI events and warnings; use CSV for tabular review. A protective apostrophe in formula-like torrent CSV paths is an export representation, while JSON retains the original path.
The reports remain local and bounded. Torrent layout does not certify availability or trust, and MIDI timing does not synthesize sound or render a score. Compare the downloaded report with the original export and the receiving client or producer at the level your actual task requires.
- Use a complete download when the visible preview ends.
- Keep source bytes and report policies with the receiving task.
References
- BEP 3: BitTorrent Protocol Specification
Original info byte hashing, bencode grammar and concatenated v1 file layout.
- Mido: Standard MIDI Files
SMF types, delta ticks, PPQN and tempo timing.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
Torrent metainfo identity and layoutDerive the original v1 info-hash, declared file offsets and inclusive piece ranges from a local .torrent, then save the complete layout and a local magnet string.
Compare a torrent identity with your client and see how its declared files share pieces. The original info bytes determine the identity; no torrent client or tracker connection is needed.
Steps
- Select one original BEP3 v1 .torrent.
- Compare the info-hash, total length and declared file layout; a piece may span two files.
- Download complete JSON, CSV and magnet text and compare the identity in your torrent client.
Capabilities and limits
- One .torrent file up to 4 MiB. Up to 5,000 declared files, 100,000 piece hashes, 100,000 bencode values and nesting depth 64. Each UTF-8 path component, including the root name, is at most 4,096 bytes; repeated complete paths total at most 8 MiB. Lengths and cumulative offsets must be safe integers. Piece length is positive and at most 16 MiB. Canonical integer tokens are at most 32 ASCII bytes; a multifile path has at most 64 components after the root.
- Accepts strictly encoded BEP3 v1 dictionaries: canonical integer and byte-length tokens, raw-byte sorted unique keys, valid UTF-8 names, and exactly one of length or files. The declared hash count must match the concatenated lengths. v2/hybrid metainfo, file attributes and padding extensions reject.
- Unsafe or ambiguous paths reject: empty components, dot traversal, slash/backslash, colon, control bytes, trailing dot/space, repeated full paths and a file also used as a parent directory. The layout is metadata only and is never written to the declared paths.
- JSON, CSV and magnet downloads combined are limited to 24 MiB. If combined budgets are exceeded, the whole result rejects. The table previews 200 files and the first 240 characters per cell; text and copy show a summary plus 20 files. All successful downloads retain complete paths and every piece hash. Formula-like CSV paths get a protective apostrophe; JSON preserves originals.
- The info-hash is SHA-1 of the exact original info byte span, not of the pieces field or whole .torrent. Piece ranges are zero-based and inclusive; empty files have null ranges. Contents, signature, trust, tracker availability and peers are not checked. Magnet text contains only xt and dn and makes no network request.
MIDI note timeline queryConvert local SMF 0/1 ticks through the full tempo map into note seconds, then query a time range, track and channel and save every original event and note.
Find the notes overlapping a specific second in an exported MIDI file. Changes of tempo affect every later tick, so the report integrates the complete global tempo map before applying your filters.
Steps
- Select an original SMF 0/1 PPQN MIDI file.
- Optionally set start/end seconds, track or channel; leave a field blank to keep it unconstrained.
- Review selected note spans and warnings, then save the complete JSON and all-note CSV.
Available options
- Start seconds (blank: no lower bound)
- Enter as needed
Matches a note span that overlaps the range; start is inclusive.
- End seconds (blank: no upper bound)
- Enter as needed
End is exclusive and must be after start when supplied.
- Track (0-based; blank: all)
- Enter as needed
Use an existing track index, not a MIDI channel number.
- Channel (0-based; blank: all)
- Enter as needed
0–15; channel labels 1–16 in other software correspond to these minus one.
Capabilities and limits
- One .mid or .midi up to 5 MiB; SMF 0/1 with a positive PPQN division, at most 64 tracks, 50,000 events and 25,000 notes. Cumulative ticks in each track are at most 4,294,967,295. Type 2, SMPTE/drop-frame division, SYX dumps, truncated chunks, invalid running status and missing final end-of-track reject.
- All tempo changes contribute to one global tick-to-second map, with a default 500,000 microseconds per quarter note. Different tempos at one tick across different tracks reject; identical changes collapse. Multiple changes within the same track and tick use the last source event.
- Time queries use the half-open interval [start, end). Notes are selected when their key-release spans overlap that interval; zero-length notes use their start point. Blank start/end/track/channel fields impose no corresponding constraint. Track and channel numbers start at 0; track indices must exist. Filters never remove events or duplicate notes in downloads: each complete note carries selected true/false.
- Repeated pitch on one track/channel closes FIFO. Velocity-zero note-on means note-off. Unmatched note-offs produce a warning and no note; unclosed note-ons end at their own track end with a warning. CC64 is preserved as an event and does not extend note duration. Program state is scoped to each track/channel; no sound synthesis, score rendering or acoustic duration is inferred.
- Complete JSON and CSV combined are limited to 24 MiB and reject atomically if exceeded. The table shows the first 200 selected notes; text and copy show the summary and first 20 selected notes. Downloads retain all source events, track totals, tempo points, notes, warning details and filter flags. No MIDI device or network service is accessed.