Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
T
Tidal
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • PLN
  • Tidal
  • Repository

Switch branch/tag
  • Tidal
  • tools
  • take-master.py
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    feat(take-master): the first master came out MONO at 192 kHz — both were real · 844f3dbd
    `tidal-ears master mix` has the right recipe and this reuses it verbatim. What
    it does not know is how Ardour lays out a take, and that produced two defects
    that only appear on this material — both of which I only caught by inspecting
    the output file rather than trusting "Done:".
    
      1. MONO. Ardour writes each orbit as TWO mono files, `Take95_Tidal 04-1%L.wav`
         and `%R.wav`. Globbing all 24 into amix sums them into ONE channel. The
         stereo image is gone — and ParVagues pans deliberately (`# pan 0.8` on the
         hats, `0.2` on take_5's sleepwalker), so that is not a technicality, it
         discards a compositional layer silently. Each pair is now `join`ed into
         stereo first and the mix is 12 stereo streams.
    
      2. 192 kHz. loudnorm resamples internally to 192 kHz to measure true peak, and
         with no explicit output rate ffmpeg keeps it. A 48 kHz session produced a
         624 MB 192 kHz file carrying no extra information. `-ar` is now pinned to
         the source rate. NB this one affects every master the sister tool has made.
    
    UNIFORM TRIM, not per-stem normalisation. gain_for_stem normalises each stem
    toward a target peak, which is right for stems of unknown provenance and wrong
    for these: PLN balanced these twelve orbits by hand, on faders, while playing.
    Normalising individually rewrites that balance — measured at 4.0 dB of shift on
    Take95, mostly making the hats hotter. One trim for every stem preserves the mix
    he played; loudnorm sets the absolute level. Same conclusion take-lens reached.
    
    AND THE MEASUREMENT ITSELF HAD A TRAP. The first version used `volumedetect`,
    which reports max_volume against a fixed-point full scale and SATURATES at 0.0
    dB. Every one of these float stems read as exactly +0.0, so the derived trim was
    -6 dB when the truth needed -19.3. Twelve identical +0.0 readings is not data,
    it is a clipped instrument — `astats Peak_level` reports the real values and
    they match the sister tool's analyze pass exactly (d4 +13.3, d3 -3.3).
    
    Refuses to render if an orbit has only one side, rather than panning it hard.
    Verifies channels and rate of its own output and exits non-zero if either is
    wrong — the check that would have caught both original defects.
    PLN (Algolia) authored Aug 02, 2026
    844f3dbd
take-master.py 10.5 KB
EditWeb IDE
×

Replace take-master.py

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.