Making a 40-hour playlist survive a car trip without gaps

这篇内容暂时只有 English 版本,以下是原文。

Two summers ago I burned a 40-hour playlist onto a USB stick for a long drive. The stick was formatted exFAT, the head unit was a 2016-era Pioneer that claimed FLAC support, and about 600 of the 2,400 tracks were 24-bit/96kHz FLAC rips from Bandcamp. Symptom: on roughly every third or fourth hi-res track the unit froze for 2-4 seconds, sometimes skipped to the next folder, and once rebooted itself. Same files played fine from a phone over USB. The library was about 180 GB, so re-encoding everything was not something I wanted to do blind.

First I checked whether it was tagging or decoding. I ran a quick scan to list sample rates and bit depths, since the head unit’s manual only promised “FLAC” without qualifying it:

find /media/usb/Music -name '*.flac' -print0 \
  | xargs -0 -n1 sh -c 'ffprobe -v error -select_streams a:0 \
      -show_entries stream=sample_rate,bits_per_raw_sample \
      -of csv=p=0 "$1"' _ \
  | sort | uniq -c | sort -rn

That printed a clean split: 1,800 files at 44.1/16 and 600 at 96/24. So the freeze correlated with the hi-res set. My fix was to keep the 44.1/16 files untouched and downsample only the 96/24 ones into a parallel tree, preserving relative paths:

while IFS= read -r -d '' f; do
  rel="${f#/media/usb/Music/}"
  out="/media/usb/Music16/${rel}"
  mkdir -p "$(dirname "$out")"
  ffmpeg -v error -i "$f" -ar 44100 -sample_fmt s16 "$out"
done < <(find /media/usb/Music -name '*.flac' -print0)

I then copied tags over with a small metaflac pass and rewrote the playlist paths. The car stopped freezing, and honestly I could not hear the difference on stock speakers at highway speed.

The mechanism, as best I understand it: the head unit’s decoder buffers a fixed number of samples, not bytes, and the USB controller on that generation chokes when it has to refill a 96/24 stream while also reading directory metadata. Downsampling cut the byte rate roughly in half and kept the buffer fed. The cost is real: I now maintain two libraries, and any new hi-res purchase has to go through the same conversion step or it will stutter again.

Where this breaks: it only helped because the files were genuinely hi-res. If your freezes happen on 44.1/16 too, the problem is probably the stick’s write speed or a fragmented FAT table, and re-encoding will waste a weekend. I also hit a trap with files that had embedded cover art over 2 MB; the unit would hang while loading the image even after downsampling. Stripping art above a size threshold fixed that. And do not trust -sample_fmt s16 alone if the source has odd channel layouts; check with ffprobe first or you will get silent mono files.

What I still do not know: whether the buffer theory holds for other head units, or whether anyone has measured a threshold where 48/24 is safe. If you have run into the same freeze, what sample rate did the unit actually tolerate before it gave up?

0
赞同度 100% · 0 条评论 · 8 阅读

0 条评论

支持 Markdown · 回复会实时推送给对方

还没有评论,写下第一条。