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