[BUG] CodecTinkerer converting to wrong bitrate

[lcbobit]

Tubifarry Version

V2.0.4.1

Lidarr Version

V3.1.2.4913

Operating System

Docker

Bug Description

Everytime an album in flac gets downloaded, the conversion with Codec Tinkerer is done with VBR smaller than specified. Problem seems to be, that flac files got detected with 0kbps bitrate, altough the bitrate in Lidarr is shown correctly on import:
Track 1: 2026-02-08 12:39:41.4|Debug|AudioTag|Audio Properties: Flac Audio, Bitrate: 1002, Sample Size: 16, SampleRate: 44100, Channels: 2
Track 2: 2026-02-08 12:39:47.1|Debug|AudioTag|Audio Properties: Flac Audio, Bitrate: 1020, Sample Size: 16, SampleRate: 44100, Channels: 2
E.g.
Custom Conversion Rules
flac -> mp3:320

The result is an album with:
MP3 – 264 kbps
MP3 – 277 kbps
MP3 – 274 kbps
MP3 – 271 kbps
MP3 – 273 kbps
MP3 – 276 kbps
MP3 – 279 kbps
MP3 – 280 kbps
MP3 – 283 kbps
MP3 – 266 kbps

Source was Flac:
FLAC – 1002 kbps
FLAC – 1020 kbps
FLAC – 1004 kbps
FLAC – 977 kbps
FLAC – 1011 kbps
FLAC – 981 kbps
FLAC – 989 kbps
FLAC – 994 kbps
FLAC – 967 kbps
FLAC – 984 kbps
FLAC – 1016 kbps

Steps to Reproduce

1. Setup codec tinkerer to convert flac to mp3:320
2. Download flac album
3. Check the conversion result

Expected Behavior

Output should be 320kbps mp3

Trace Log Files

Logs

2026-02-08 12:39:59.3|Trace|AudioConverter|Track bitrate found for /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 01 - <TRACK>.flac at 0kbps
2026-02-08 12:39:59.3|Debug|RuleParser|Parsing rule: flac -> mp3:320
2026-02-08 12:39:59.3|Debug|AudioConverter|Matched conversion rule: FLAC->MP3:320
2026-02-08 12:39:59.3|Debug|RuleParser|Parsing rule: flac -> mp3:320
2026-02-08 12:39:59.3|Debug|AudioConverter|Matched conversion rule: FLAC->MP3:320
2026-02-08 12:39:59.3|Debug|AudioConverter|Converting FLAC (0kbps) to MP3 (320kbps): /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 01 - <TRACK>.flac
2026-02-08 12:39:59.3|Trace|AudioMetadataHandler|Converting <TRACK>.flac to MP3 at 320kbps
2026-02-08 12:39:59.3|Trace|AudioMetadataHandler|Extracting audio from video file: <TRACK>.flac
2026-02-08 12:39:59.4|Trace|AudioMetadataHandler|Successfully extracted audio to <TRACK>.flac
2026-02-08 12:39:59.4|Trace|AudioMetadataHandler|Looking up audio format: MP3
2026-02-08 12:39:59.4|Trace|AudioMetadataHandler|Applied quality parameters for MP3: -q:a 0
2026-02-08 12:39:59.4|Trace|AudioMetadataHandler|Starting FFmpeg conversion
2026-02-08 12:39:59.9|Info|AudioConverter|Successfully converted track: /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 01 - <TRACK>.mp3


2026-02-08 12:40:02.8|Trace|AudioConverter|Track bitrate found for /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 02 - <TRACK>.flac at 0kbps
2026-02-08 12:40:02.8|Debug|RuleParser|Parsing rule: flac -> mp3:320
2026-02-08 12:40:02.8|Debug|AudioConverter|Matched conversion rule: FLAC->MP3:320
2026-02-08 12:40:02.9|Debug|RuleParser|Parsing rule: flac -> mp3:320
2026-02-08 12:40:02.9|Debug|AudioConverter|Matched conversion rule: FLAC->MP3:320
2026-02-08 12:40:02.9|Debug|AudioConverter|Converting FLAC (0kbps) to MP3 (320kbps): /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 02 - <TRACK>.flac
2026-02-08 12:40:02.9|Trace|AudioMetadataHandler|Converting <TRACK>.flac to MP3 at 320kbps
2026-02-08 12:40:02.9|Trace|AudioMetadataHandler|Extracting audio from video file: <TRACK>.flac
2026-02-08 12:40:03.0|Trace|AudioMetadataHandler|Successfully extracted audio to <TRACK>.flac
2026-02-08 12:40:03.0|Trace|AudioMetadataHandler|Looking up audio format: MP3
2026-02-08 12:40:03.0|Trace|AudioMetadataHandler|Applied quality parameters for MP3: -q:a 0
2026-02-08 12:40:03.0|Trace|AudioMetadataHandler|Starting FFmpeg conversion
2026-02-08 12:40:04.9|Info|AudioConverter|Successfully converted track: /data/media/music/<ARTIST>/<ALBUM (YEAR)>/<ARTIST> - <ALBUM> - 02 - <TRACK>.mp3

Log Checklist

• I have enabled Trace logging in Lidarr before reproducing the issue

Screenshots

Screenshots

Additional Context

No response

[TypNull]

Hi, as stated in #123, Tubifarry uses VBR by design, this is intentional, not a bug.

When you set mp3:320, the bitrate value is mapped to the closest VBR quality level (V0 in this case, averaging ~245-260kbps). This is how LAME VBR works and it's generally considered the better encoding strategy.

I still struggle with the reasoning for wanting CBR here. Yes, I could force -b:a 320k at the ceiling, but consider what that actually means: you're choosing MP3, one of the weakest lossy codecs available and then asking for the least efficient compression mode, just to get a number that looks right in your file properties. The actual perceptual quality difference between V0 and CBR 320 is essentially nonexistent.

If bitrate consistency and quality matter to you that much, I'd strongly recommend switching to Opus, which gives you better transparency at half the bitrate. Or if compatibility is the concern, V0 is already a standard for MP3 encoding, it's what people in the audio community recommend.

That said, I'm open to hearing concrete use cases where CBR 320 is genuinely needed. If there's a real-world scenario I'm not seeing, feel free to make the case and I'll reconsider.