Kijai

/

LTX2.3_comfy

like 503

I'm not sure what you mean exactly, I'm not hearing anything obvious when comparing to the full model, using that same lora at 0.6:

bf16:

int8_convrot:

I know it's more aggressive quant, so it's not impossible, but I'd need to be able to reproduce the problem to fix it.

Using headphone and play it loud: You should hear that in your own example, int8_convrot: The difference is clearly at second 14 (guys in the background shout slowly "yeah..." before the reporter continues with "There it is, folks..."), where it's more tinny/hissing than in the bf-16 example. But in your bf16- version the sound isn't perfect either between second 14-20. I assume because the reporter shouts and that affects the rest of the sound part (which is a lesser problem, if any, with the "transformer_only_fp8_scaled version"). If you use your example with a soft-spoken voice (a guy who just talks to another person) it becomes clearer.
If there's something I could add to reproduce the problem let me know.

The comparison is always against bf16, closer to that = better quant. If you prefer fp8 it's because the worse quant makes it softer or something, which then should be compensated by something else in the workflow. This would align with your experience with the winnougan int8 quants, since they don't seem to be using convrot, so they're also further from bf16.

This would align with your experience with the winnougan int8 quants, since they don't seem to be using convrot, so they're also further from bf16.

There were also differences for your int8convrot version with certain LoRAs, which increased the noise issue (e.g. Dual Character, or VBVR-I2V-official-comfyui). Me, with RTX3050, just thinks int8 runs faster (it does), fp8 is lighter, and wondered why the sound issue (pre- spatial-upscaler-x2-1.1) returned. This will sooner or later lead to more issues by other VRAM-poor users. I did not know about the strong disadvantage of int8 towards b16 in comparison (which aren't visible in image gen for normal eyes, and: the video quality of int8convrot is great, btw!). I see your point, for audio that's the deal with faster generation but I'll return to fp8 scaled for audio (and I'm still using landslide phone because the audio is fuller).

I forgot to mention, that audio is no problem for your distilled int8conrot version. Here is a fast done example with low resolution, focusing on dialogue, no LoRAs, to highlight the issue - it's strikingly bad for the dev version.

for dev-transformer-only-int8-convrot:

for distilled-transformer-only-in8-convrot:

And also: silveroxide's ten days old int8convrot ( https://huggingface.co/silveroxides/LTX-2.3-Quants/blob/main/ltx-2.3-22b-dev-dare-ties-distilled-1.1-transformer_only-int8-convrot-simple.safetensors ) should be more similar to your dev int8convrot than winnougan's int8 version, it also does not have the sound issue (if I'm not mistaken, silveroxide used the dev version and included distill loras or is "dare ties" conversion too far away from a comparision? At least I generated it as a dev with no distill LoRAs, thinking they were merged in).

silveroxide dev-dare-ties-distilled-1.1-transformer_only-int8-convrot-simple:

Your distilled int8conrot is the clear winner because it follows the prompt also more closely, never confuses the speakers.

You wrote that comparatively it's always BF16 against lower quant. But the fp8- versions have good audio. Is the fp8- audio really just "softened" by something, to sound good? Since there are no obvious audio discrepancies between dev and distill for the fp8 versions, does it really matter as an explanation for the glaring difference in sound quality between int8convrot-dev and int8convrot-distill?

should be compensated by something else in the workflow.

Is this again an user error, like the VL text-encoder thing for Flux2-kv, please no... damn, yes, kind of: The distill LoRA for the second pass is different than the one for the first sampler. I've kept it as it is because I've read somewhere:

LTX2.3-22b-distilled-dynamic_fro09_avg_rank_105_bf16 is the best choice for second pass, the upscaling at 0.6 strength.

Turns out it's bad for int8convrot-dev and should be replaced with LTX2.3-22b-Distilled-1.1_dynamic_fro09_avg_rank_111_bf16 for 2nd sampler. That makes a difference, the audio is better for int8convrot-dev. (All workflows are included in .mp4- files.) Case solved!? Except while it's now better, noisy AI-hissing is still there, but less audible, as in the 14th second of your int8convrot-dev example.

dev-transformer-only-int8-convrot +dist lora 1st pass 0.4/ 2nd pass 0.6

Now down to a question of strength, for the Distilled-1.1_dynamic_fro09_avg_rank_111_bf16 LoRA.

• 1st pass 0.4 and 2nd pass 0.6 is good for int8convrot-dist, but what could be optimal for int8convrot-dev?
• Decreasing the strength made it worse.
• I'm now satisfied with 1st pass 0.6 and 2nd pass 0.8.

dev-transformer-only-int8-convrot +dist lora 1st pass 0.6/ 2nd pass 0.8 - Multimodal Guider - no NAG node

dev-transformer-only-int8-convrot +dist lora 1st pass 0.6/ 2nd pass 0.8 - NAG - no Multimodal Guider

The strength values are higher than recommended but the audio is good with NAG node or with LTX's Multimodal Guider node.