mikkeli
c965fbf5fe
Building the transect visualisation (Song274Transect) is what exposed problems in the lyric and its index: syncing nodes to the lyric showed 紅葉山橋 lighting up although it is not on this road (it is on R452), 下福山橋 and オロロップ橋 sitting at the wrong km, and lines timed against the wrong stretch. They were fixed upstream in the wiki (ncmr-songs 7af0f48, "274: drop 紅葉山橋, fix オロロップ橋 and 下福山橋, re-timed lyric"), and the lyric deliverables here follow. 274.lrc — byte-identical copy of the wiki LRC at 7af0f48: 紅葉山橋 removed; 紅楓橋 through 楓信号場 re-timed (1:35.24–1:55.54) with 夕張市楓 at 1:45.77; 登川トンネル at 2:05.23 and its section end at 2:06.62; 稲里トンネル's section end at 4:25.27. 下福山橋 and オロロップ橋 keep their timing; their km were corrected in the roster and index. 274.srt — regenerated with scripts/lrc2srt.py, 116 cues. 274.ass — events follow the LRC: district headers as transparent_title spanning their section, 東に続く as transparent_lyrics_jp, spacers as empty events, the final line held 5 s. The Aegisub header and all 17 styles are untouched. 117 events -> 116. route/ — copied from novoyuuparosk-wiki/ncmr-songs wip/274, where it is generated; read-only here, and its README says so. src/song-274/data.ts loads 274-route.json, 274-lookup.csv and 274-lyrics-index.csv, plus the two approach stubs: 274-route-west.json (always drawn as covered) and 274-route-east.json (painted after 東に続く). Also carries the district bands, the GeoJSON and the reference page. The route shapes are single clean polylines: no second-carriageway points in the divided sections, km strictly increasing. Verified: all 116 ASS events and SRT cues match the LRC's order, text and timestamps; every sung node in the index joins to the roster at matching km. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PLt25nCVMsoroKALYUBu6u
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) package-lock.json— see below
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.
Why there is no package-lock.json
Deliberate, not an oversight. Work happens on both Windows and Linux, and two things make a lockfile a liability here rather than a safeguard:
- There is nothing for it to pin. Every dependency in
package.jsonis pinned to an exact version — no^, no~. A plainnpm installon any machine resolves to the same versions the lockfile would have recorded. - A lockfile is platform-specific. It records the resolved tree, including
the optional native binaries for whichever OS generated it (
@rollup/rollup-linux-x64-gnu,@rollup/rollup-win32-x64-msvc). Committed from Linux it is wrong on Windows, andnpm cirefuses outright rather than adapting, since its whole purpose is to reproduce the recorded tree exactly.
So it would be strict about the wrong thing: breaking installs across machines while guarding versions that were never floating. Revisit this if a dependency is ever loosened to a range, or picks up transitive drift that exact pinning cannot control — at that point the lockfile earns its friction.
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.