BitrateCraft · Reference and desk · bitratecraft.org

Disclaimer: Independent technical documentation and configuration guide. Not affiliated with The HandBrake Team. No software downloads hosted

About the Editorial Desk

BitrateCraft is written by a small editorial desk that documents transcoding practice for people who operate the tools. This page explains who writes the material, how a claim is checked before it is published, and what the desk deliberately refuses to publish. It exists so that a reader can judge the reliability of an article without having to guess at the process behind it.

Who writes the desk

The desk is staffed by working video engineers and technical writers. Every contributor has run conversions in production: encoding farms, broadcast hand-offs, archive migrations, and workstation batches where a preset must behave the same way on a hundred files as it does on one. Contributions are reviewed by at least one other engineer before publication, and the reviewer is named in the article history rather than left implicit.

The team uses HandBrake, FFmpeg and Shutter Encoder as reference implementations because they cover the three working styles described elsewhere on this site: a preset-driven panel, an explicit argument grammar, and a queue built around a bundle. A statement that holds for all three is a statement about the underlying media model; a statement that holds for only one is labelled as such.

How claims are verified

Nothing is published from memory or from documentation alone. Each factual claim is tested against observed behaviour of the current release, on real files, and the observation is written down before the prose is drafted. The desk uses a short internal checklist for this:

1. State the claim in one sentence, with the exact setting or flag it concerns.
2. Reproduce it on a source file with known properties: known frame rate, known channel layout, known duration.
3. Change one variable at a time and record what moves and what does not.
4. Compare the generated argument list or log against the documented expectation.
5. Inspect the output structure, not only the picture, and record the measured result.
6. Retest after any release that touches the encoder, filter or container involved.

Where a behaviour depends on hardware, the desk records the model rather than generalising from a single run. Where two tools disagree, both results are printed side by side and the difference is described as a difference, not resolved by preference. Where a test is inconclusive, the article says so and marks the section as unverified rather than softening the language.

What the desk never publishes

The desk maintains a firm list of material it will not carry, regardless of demand. It does not publish instructions for obtaining, extracting or redistributing copyrighted media, and it does not discuss protection mechanisms at all. It does not publish binaries, package files or links to them; articles describe settings and behaviour, and leave the reader to obtain the tools from their own sources. It does not publish commercial terms of any kind: no rates, no fee schedules, no sales language, and no claims about which tool a reader should pay for.

It also refuses to publish benchmark tables that cannot be reproduced. A speed comparison without the source properties, the hardware and the exact arguments is noise dressed as data, and it is omitted rather than approximated. The same applies to quality comparisons: a screenshot pair without the encoder settings is an anecdote, and the desk treats it as one.

How corrections are handled

Corrections are welcome and are treated as part of the record. A report should name the page, quote the sentence, and describe the observation that contradicts it, including the tool version and the exact settings used. When a correction is accepted, the article is revised and the change is noted with its date; when it is rejected, the desk replies with the reasoning and the test that supports the original claim. Material that is merely inconvenient is not removed, and material that is wrong is not defended.

Editorial address

Correspondence about a specific page should include the URL path, the tool and version, and the settings used. Reports that name those details are answered faster because they can be reproduced on the first attempt.