changelog: tighten 1.6.1, and record two entries it was missing

The entries had grown into narrative paragraphs; each is now the outcome
first and the mechanism in a sentence or two. The website changelog page
mirrors libfreemkv's, so it inherits this directly.

Two things that shipped in this cycle were not in it at all:

dir:// as a source. It was pulled from 1.6.1 on 2026-08-05 because the
folder reader produced a wrong title list on a real DVD. That defect was
the CSS descramble bug below, fixed since — the acceptance suite now
shows a folder reporting the same 38 titles as its ISO, with matching
streams, languages and runtime, and the CLI has been wired for it all
along. It ships, so it is listed.

The CSS title-table corruption itself: a disc enumerating 38 titles
produced a decrypted image enumerating 10, silently, at exit 0. That is
a data-integrity fix a user needs to know about.

CHANGELOG.md

@@ -4,41 +4,38 @@
 
 ### Added
 
-- **An existing disc image can now be decrypted without the disc.**
+- **A disc image can be decrypted without the disc.** `iso://In.iso
-  `iso://In.iso iso://Out.iso` writes a decrypted image from an encrypted one;
+  iso://Out.iso` writes a decrypted image from an encrypted one. Ripping from a
-  previously the only way to get a decrypted image was to rip the disc in a
+  drive is unchanged and still uses the recovery path, because multi-pass retry
-  drive. Ripping from a drive is unchanged and still uses the recovery path —
+  and damage handling exist for media that returns read errors — a file does not.
-  multi-pass retry, resume, damage handling — because that machinery exists for
+- **A disc kept as a folder can be read directly.** An extracted `VIDEO_TS` or
-  media that returns read errors, which a file does not.
+  `BDMV` folder works anywhere an image does, as a source or a destination.
+  A decrypted backup is judged by its content, not by whether a leftover `AACS`
+  directory is present. 3D folders are refused rather than silently mishandled.
 
 ### Fixed
 
-- **Blu-ray titles built from several clips could run minutes longer than the
+- **Blu-ray titles built from several clips ran minutes long, with sound
-  film, with sound drifting ahead of picture.** Many discs store the feature as
+  drifting ahead of picture.** Such discs store the feature as a chain of clips
-  a chain of clips and use the playlist to say which part of each one to play —
+  and use the playlist to say which part of each to play. Those marks were never
-  the parts overlap or skip, and a player follows the playlist's marks. freemkv
+  read, so skipped stretches became dead time and overlaps put the same moment
-  never read those marks. It joined the clips by guessing from their internal
+  on the timeline twice. One title declared 2h11m and contained 2h13m; the worst
-  timestamps, so every skipped stretch became dead time in the output and every
+  ran 13 minutes long, with audio adrift from about half an hour in. Every track
-  overlap put the same moment on the timeline twice, which shoved the audio
+  is now placed by the byte offset it was read from, so each clip contributes
-  ahead of the video and left it there. One affected title declared 2h11m and
+  exactly the span the playlist gives it. Measured on four affected titles:
-  contained 2h13m; the worst ran 13 minutes long. Sound came adrift about half
+  timelines now land within 12 ms of the declared runtime. Single-clip titles,
-  an hour in and stayed adrift. The marks are now read, each clip contributes
+  DVDs and HD-DVDs were never affected.
-  exactly the span the playlist gives it, and every track crosses a join on its
+- **A decrypted DVD image could lose most of its title list.** The scrambling
-  own frame — so a title runs exactly as long as the disc says it does. Titles
+  test read two flag bits and nothing else, which is only meaningful inside an
-  made of a single clip were never affected and are unchanged, as are DVDs and
+  MPEG-2 pack. Applied to arbitrary sectors it also matched IFO and filesystem
-  HD-DVDs.
+  structures: on a real disc it destroyed 1912 bytes of the sector carrying
-- Chapter marks and title durations on NTSC DVDs ran roughly 0.1% short —
+  `TT_SRPT`, so a disc enumerating 38 titles produced an image enumerating 10,
-  about 3.6 seconds per hour — so a mark near the end of a feature could
+  silently, at exit 0. Descrambling now requires a pack start code.
-  land several seconds before the scene it names. On a 67-minute title the
+- **Chapter marks and durations on NTSC DVDs ran about 0.1% short** — some
-  drift reached about 4 seconds. The playback times a DVD stores are
+  3.6 seconds per hour, so a mark near the end of a feature could land seconds
-  timecode, and on an NTSC disc the timecode runs slightly slow against the
+  before the scene it names. DVD times are timecode, and NTSC timecode ticks
-  clock: its seconds field ticks every 30 frames while the video actually
+  every 30 frames while the video runs at 30000/1001 fps. They are now converted
-  runs at 30000/1001 frames per second, so 30 frames take 1.001 real
+  through an exact frame count. PAL discs were never affected.
-  seconds, not 1.000. Those times were being read as if they were plain
-  seconds, which is where the missing 0.1% went. They are now converted
-  through an exact frame count, so every mark lands on a real frame
-  boundary no matter how long the title runs. PAL discs were never affected
-  and their timings are unchanged.
 
   Reported and fixed by AnimeFN (freemkv#25, libfreemkv#1).