A track's normalization gain is not read #72
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A track's normalization gain is not read.
/Items?Recursive=true— 30 tracks carry a value upstream and none here:-5.75-10.08NormalizationGainis the ReplayGain a file declares. TheBaseItemsschemahas the column (
LUFS,NormalizationGain) and this port writes neither, so aclient normalising playback volume has nothing to work from.
Upstream reads it during the probe. Worth checking which tag names it takes and
whether the value is the gain or is derived from LUFS.
Fixed. Both were broken on the read path and the write path — the live
databases are upstream's own scan, so the columns were already populated and
this server still reported nothing.
NormalizationGainis not from the probe.AudioFileProber.cs:456readsthe tag
REPLAYGAIN_TRACK_GAINout of the tag library's additional fields,strips a case-insensitive
dbsuffix, and stores it if it parses finite —audio only.
DtoService.cs:1144answers-18 - LUFSwhen a LUFS is stored andthe gain otherwise.
LUFSitself is written only by a scheduled loudness passthis port does not run.
That the tag library reads it rather than ffprobe is load-bearing: 42 of the
83 gain-carrying files in the library are MP3s whose gain lives in an APEv2 tag
ffprobe does not report at all.
IndexNumberEndhas no column — it is serialized intoBaseItems.Data.jellyfin-namingalready parsed it correctly; the scan dropped it, the writenever carried it, and the read never looked in the blob.
NormalizationGainIndexNumberEndGains from a real scan of six library files are bit-identical to upstream's
answer key, and a rescan still writes nothing — every row's
Data,DateLastSavedandNormalizationGainbyte-identical after a second pass.