irene
2c6e227c82
`feat/bom-generator` carried one commit that never landed on master: file
content hashes in the BOM ("v2 with hashes"). The Python rewrite dropped that
capability, so port it forward rather than losing it when the branch goes.
- `--hash` records a short BLAKE2b digest per file. Opt-in, because it reads
every asset in full and that is wasted work for a plain inventory.
- Hashes are streamed in chunks with `hashlib.blake2b`, not `md5` via haveged
imports, and not whole-file reads — these assets run to hundreds of megabytes.
- YAML gains `hash:` after `size:`; Markdown gains a hash column only when
hashes were requested, so the common table stays readable.
Fix a pre-existing bug found while testing: the BOM marker was written as
`; generated by ...`, but `;` is not a YAML comment, so every generated BOM
failed to parse with "mapping values are not allowed here". Now `#`. Verified by
re-parsing output from both the PyYAML path and the built-in fallback writer.
Sizes alone cannot tell you whether an asset changed; a same-length re-render
keeps the byte count identical. That is the gap the hash closes.
Video-related files for NCMR songs
This repo houses the code-like files for NCMR music videos. Binary assets live elsewhere.
Structure
Repo state: workspace under construction.
masteris not locked in yet — it is still being assembled as the shared template. Until it is locked, any branching strategy is fine and template/tooling work can land onmasterdirectly. The branch conventions below describe the intended end state, not a rule currently in force.
master branch — shared template
This branch holds the common scaffolding:
- Remotion project — entry point, root component, and a placeholder composition
scripts/— Python toolchain (stdlib only) for subtitles, ffmpeg and asset manifests- Build config — TypeScript, ESLint, Prettier, Remotion studio
src/ vs scripts/
Two directories, two jobs:
src/— Remotion input only. Everything here is compiled bytsc/Remotion and linted bynpm run lint.scripts/— operator tooling. Python, standard library only, run directly (python3 scripts/tools.py --help). Nothing here is part of the Remotion build.
Keep the boundary sharp: anything the video build compiles belongs in src/, and
anything you run by hand belongs in scripts/.
Song branches
For each song, create a branch <song-name>/master (and optionally feature branches
like <song-name>/synced-lyrics-remotion):
git checkout -b <song-name>/master
Copy the shared template into the song branch, then add song-specific files:
mkdir -p <song-name>
# Place your song-specific compositions, assets manifests, etc.
Once master is locked in it remains protected and mostly immutable. Until then,
song branches are a rehearsal for that end state, not a requirement.
Guideline
Git-ignored (not tracked here)
- Binary input assets (audio, images, fonts, material video clips)
- Video output (
out/, rendered files)
For untracked input assets, a bill of materials listing everything and explaining
what each file is will be mandatory. Keep it as BOM.md alongside your song assets.
Branching
master— minimal template (protected once locked in)<song>/master— song-specific work<song>/<feature>— parallel features for a song
Once master is locked, this repo's branching rules supersede any generic git
operation conventions. Before that point, use whatever is convenient.