Thank you both for reporting your results. The difference between your experiences is very useful to know.

In our basic V3.7 continuation tests, character state, action, motion, and audio could continue across chunk boundaries. However, I agree that V3.7 was not documented clearly enough. The correct prompting format, continuation settings, audio settings, and chunk workflow were difficult to understand and reproduce. If a workflow only works when the user already knows the correct combination of settings, then the manual and user experience still need improvement.

I do not want to assume that this was simply a user mistake. The reported character-state reset, obvious audio or music restart at chunk boundaries, and the first three or four dialogue words being skipped are all issues that should be checked carefully.

For V3.8, I want to make both the behavior and the instructions much clearer. This includes practical examples for prompts, timestamps, chunk continuation, Audio Continuity, reviewing a chunk, retrying it, and continuing from saved progress.

Thank you again for testing Continuum and discussing the difference openly. This is an area I definitely want to make reliable and understandable.

@velanteg Thank you for clarifying. I understand now: the scene is being reset during continuation, producing different characters and a different background, even though the prompts follow the recommended format.

This is more severe than gradual quality drift. I would classify it as a character/background continuity reset at a chunk boundary.

Could you please provide:

1. The exact workflow JSON

2. The Continuum version

3. Generation Mode / Run setting

4. Chunks and Seconds per Chunk

5. Continuity setting

6. Whether Audio Continuity is enabled

7. The exact Sequence Prompt

8. Which chunk first changes the character or background

9. Model, LoRA, Spectrum, Sol, Sage, or other wrappers used

10. If possible, the generated video showing the reset

Please do not simplify the workflow before sending it. The exact saved workflow is important for reproducing the same behavior.

@hatt2 Thanks! Just to confirm — when you say “reference audio,” do you mean the Driving Audio input in Continuum?

@hatt2 Thanks for clarifying. Yes, I understand now — you mean Reference Audio (Optional) and Reference Audio VAE (Optional), not Driving Audio.

You’re right that the current Continuum implementation only exposes one Reference Audio. I’m going to review and implement support for up to 3 Reference Audios, following the native MiniMax H3/Core behavior as closely as possible.

Driving Audio will remain a separate feature and won’t be changed as part of this.

Thank you! I really appreciate you sharing your work-in-progress video and helping more people discover Continuum.

I’m especially glad to hear that the speed and color consistency are working well for you. Real-world examples like this are extremely useful while I continue improving the workflow, so thank you again for the support.

And thanks as well for your Reference Audio feedback. I understand now that you mean Reference Audio (Optional) rather than Driving Audio. I’m looking into extending this to support multiple Reference Audios, following the native MiniMax H3 behavior as closely as possible.

V3.8 is also currently in development, and several major features are already implemented. It is becoming much more production-oriented, with Render History / multiple Takes, the ability to select an earlier Take and continue from that point without regenerating everything, improved Regenerate / Resume controls, and a cleaner main interface. The idea is to make long-form generation easier to review, repair, branch, and continue without throwing away sections that are already good.

One thing that is a little different about Continuum is its design philosophy. There are already many excellent all-in-one H3 workflows, so I’m not trying to turn Continuum into another one. The main development focus is the sampler and continuation system itself — long-form generation, continuity between chunks, review, regeneration, branching, and resume. Upscaling, decoding, acceleration, and other processing can stay modular and be connected externally depending on what the user prefers.

Because of that, Continuum is probably better suited to more advanced or heavy ComfyUI users than to people looking for one completely self-contained workflow. I think it may actually suit experienced users like you particularly well, because you can choose the surrounding tools yourself and use Continuum as the long-form continuation core.

In short, the goal is not to make Continuum do everything. The goal is to make continuation itself as reliable, manageable, and practical as possible.

Those nodes are included with ComfyUI-H3-Continuum V3.7.

It looks like Continuum itself may not be installed yet.

Please install ComfyUI-H3-Continuum through ComfyUI Manager, or clone the repository into:

ComfyUI/custom_nodes/ComfyUI-H3-Continuum

Then completely restart ComfyUI and reopen the workflow.

After the extension loads correctly, these nodes should be available:

H3ContinuumSamplerV37

H3ContinuumAssembleSeamV35

H3ContinuumHiResFixV35

If you already installed Continuum and they are still missing, send me the startup console lines mentioning ComfyUI-H3-Continuum.

@hatt2 Thank you both for testing Continuum and for the kind feedback! I’m very happy to hear that you were able to generate a full minute.

I’m also glad to hear that you observed less color drift and character drift than with the other workflow. However, I would not say that Continuum eliminates drift completely. With longer generations, such as 6 × 10-second chunks, gradual changes in color, tone, contrast, texture, image quality, and sometimes character identity can still appear. I have not fully characterized the character-drift side yet, but these different types of long-form drift are among the main problems I am currently working on for V3.8.

This is a difficult problem across many long-video, multi-shot, and context-loop approaches. The challenge is to preserve continuity without freezing the motion or allowing image degradation to accumulate with every new chunk. One of the main goals of V3.8 is to find practical ways to reduce these changes while keeping the motion and continuation natural.

I also agree that the prompting and chunk workflow can feel different at first. In the current V3.8 development version, Continuum can create the next chunk, pause for review after each chunk, retry only the current chunk, and resume or regenerate from saved progress. These V3.8 features are clearer and more reliable than the earlier workflow, although they may still not be obvious at first glance.

I therefore need to prepare a clearer and easier V3.8 manual with step-by-step instructions and practical examples. It should explain the prompting approach, how to create and review the next chunk, how to retry only one chunk, and how to resume or regenerate from a saved point.

Thank you again for testing it and for the encouraging feedback. A one-minute generation is a very valuable test 🙂 If you notice where drift begins, or find prompts and settings that work especially well, I would be very interested to hear about them.

@ana25077166 Thank you—this is a very useful observation.

Just to clarify, the current public workflow is V3.7. In V3.8, I am actively investigating these long-form changes in color, contrast, texture, and image quality.

Your observation suggests that the change may develop not only at chunk boundaries, but also within a longer 15-second generation window. I therefore need to distinguish between:

drift developing inside a single long chunk;

drift accumulating when the previous chunk is reused for continuation;

visible changes introduced at the final join.

Your point about prompting is also helpful. Even when describing the same actions, List mode may offer more predictable control because every chunk receives an explicit prompt. Timeline mode is more convenient, but its automatic time-to-chunk interpretation can make the final conditioning less obvious.

I will include both the 15-second within-chunk behavior and a matched List-versus-Timeline comparison in the V3.8 investigation. V3.8 already improves reviewing, retrying, resuming, and regenerating individual chunks, but the long-form quality-drift problem is still under investigation and should not yet be considered solved.

@ana25077166 Thank you very much—this is extremely valuable information.

Your observation confirms that the long-form quality change is not explained only by Continuum’s chunk handoff. The H3 model variant, LoRA, and step count can also affect quality inside a single longer generation window. Your result with minimax_h3_fl2va_pruned_int8_convrot, no LoRA, and 25 steps is especially useful because it gives a cleaner reference condition.

I will treat model/LoRA/step configuration as a separate factor in the investigation, rather than assuming that every color, contrast, or texture change comes from continuation alone. I also appreciate the comparison with h3_hybrid_fl2va_ref2va_b20-49; it may be a useful candidate for a controlled comparison later.

The Scail2 helper is also an interesting reference. I will study the anchor-frame noise-mask idea carefully, but I do not want to copy it blindly: MiniMax H3 has different latent, audio, and continuation contracts, so it needs to be tested as an isolated experiment with the existing workflow kept unchanged for comparison. The goal is to reduce degradation without freezing motion or breaking audio continuity.

Thank you again for sharing the exact models, settings, and the Scail2 reference. This kind of practical testing is very helpful for narrowing down the real cause.

@Xarfai @hatt2 @Xarfai Thank you — this is very useful, and I think you may be pointing to an important part of the problem.

If you can generate one or two minutes without noticeable color or contrast drift, then prompting structure may be a much larger factor than I initially assumed. Xarfai’s example is especially helpful because it shows a clear method: divide the sequence into longer sections, then restate the subject identity, reference priority, retained attributes, exclusions, camera blocking, and sound design for every section.

This may explain why some shorter or more automatic prompts gradually lose control even when the continuation settings are unchanged. It also supports the earlier observation that explicit List prompts may be more predictable than Timeline interpretation.

I still need to separate prompting effects from the model, LoRA, step count, references, and Continuum’s continuation transport. I will therefore run a matched comparison using:

1. a short conventional List prompt;

2. a detailed section-by-section List prompt using this structure;

3. the same actions expressed in Timeline mode.

The model, seed, references, step count, and continuation settings will remain identical.

@hatt2, if possible, could you share the model, LoRA, step count, chunk configuration, Continuity setting, Audio Continuity setting, and a sanitized example of the prompt structure used for the Supergirl video? A workflow JSON would be even more useful if you are comfortable sharing it.

@Xarfai, thank you for the detailed example. I will not reproduce its subject matter in the public documentation, but the prompting structure itself is extremely useful. I can adapt the same method into a general, safe example for the V3.8 manual.

This does not yet prove that every drift case is caused by prompting, but it gives us a strong and testable alternative hypothesis. It may also lead to a much better step-by-step prompting guide for Continuum.

Thank you—your comparison with v3.4 was genuinely helpful. I spent about a week testing different continuation approaches and ways to reduce accumulating artifacts. Some individual tests improved, but I haven’t found a reliable fix that consistently preserves motion and continuity.

V3.8 is now available, but I don’t want to present it as a confirmed fix for the quality issues you reported. Its main improvements are usability, including reviewing each chunk before continuing.

My testing has mainly used the pruned INT8 model. BF16 might behave differently, but I haven’t verified that, and I wouldn’t recommend downloading a much larger model on that assumption alone. The visible transitions and the apparent return to the original starting frame may also need to be investigated separately.

If v3.4 is giving you better results, it’s reasonable to keep using it for now. Could you share the exact model filename you used, and whether it was the same for both versions? That would help narrow down the difference.

It’s possible through Second Pass, but the wiring is a bit involved, and I haven’t tested that particular latent upscaler.

For a simpler workflow, I’d suggest generating and assembling the video normally, then upscaling the finished video with a separate video-upscaling tool or service. That leaves Continuum’s original latent continuation untouched and avoids the additional Second Pass setup.

I mainly use the native-resolution output myself, so I can’t offer a verified high-resolution workflow for that upscaler. Second Pass is available as an advanced option, but external post-processing is probably the more straightforward route here.

It depends on whether you want to generate new audio or use a specific existing track.

For a song or lip-sync video, I’d use Driving Audio. It uses your supplied track as the final audio, while Reference Audio guides newly generated audio, which can turn out quite different from the reference. Driving Audio doesn’t guarantee perfect lip sync, though.

This is an example I made using a first image and a song supplied through Driving Audio:
https://civitai.red/images/142091880

There is a processing-time trade-off. In that particular test, generation took roughly 1.8× as long on my setup, so it isn’t a speed improvement. That figure will vary with the workflow and hardware.

The distinction between Driving Audio and Reference Audio is the same in V3.7 and V3.8. What V3.8 adds is Review Each Chunk, so you can watch and listen after a chunk finishes, then decide whether to continue or retry instead of waiting for the whole sequence.

If your goal is to generate new audio rather than reuse a track, Driving Audio won’t solve that—it serves a different purpose.

Sorry for the confusion and for disrupting your working V3.4 setup. V3.8 no longer exports the older V3.4 node IDs, and I should have provided a clearer rollback path.

The complete V3.4 implementation is preserved here:

https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum/tree/codex/v34-hybrid-flf-00031-20260821

You can clone it with:

cd ComfyUI/custom_nodes
git clone --branch codex/v34-hybrid-flf-00031-20260821 --single-branch https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum.git

Before cloning, please move the existing V3.8 ComfyUI-H3-Continuum folder out of custom_nodes. Do not leave V3.4 and V3.8 installed side by side, because duplicate installations can conflict.

The confirmed V3.4 commit is:

d3dab7bcb0ee4fd9c43305f7ec45725cbd33079c

The V3.4 workflows are included under:

examples/workflows/MiniMax_H3_Continuum_V34.json
examples/workflows/MiniMax_H3_Continuum_V34_turbo.json

Your prompt is not fundamentally wrong, and I would not attribute the transitions and character morphing entirely to prompting. One conflict is the “20-second video” instruction: if you are generating 4 × 8-second chunks, the total is 32 seconds. I recommend removing that duration sentence or changing it to match the actual total.

Phrases such as “continuous” and “no cuts” can guide H3, but they cannot guarantee a seamless boundary between separately sampled chunks. The prompt is also very detailed, so simplifying repeated appearance and motion constraints may help, but if the same setup worked better in V3.4, continuing to use V3.4 is reasonable.

Thank you for the detailed comparison. I am still investigating the transition and character-morphing behavior, and I am not treating V3.8 as a confirmed quality fix.

@Xarfai Thanks for testing this further — the additional results are very helpful. Since 4×15s also fails in Generate Full Video, this appears to extend beyond Review mode. The difference between the successful 2×15s test and the failing 4×15s test is an important clue.

I haven’t confirmed the cause yet, so I can’t say whether an empty or incorrect video segment is being passed to the next chunk. I’ll include both modes in the investigation. For now, 5-second chunks appear to be a working workaround in your tests.

How many 5-second chunks did you test, and was that with the same one-minute input video? Thanks again for helping narrow this down.

If you want the second 10-second segment to continue from the first one, do not generate them as two separate one-chunk videos.

In the V3.8 sampler, set:

Chunks: 2

Seconds per Chunk: 10

Total Length: 20 seconds

Continuity: Balanced — 22 frames

Base Seed: keep it fixed

Control After Generate: fixed

Audio Continuity: true

You then have two options:

Automatic generation

Set Run to Generate Full Video and press Queue once. Continuum generates Chunk 1, uses its ending context to generate Chunk 2, and the workflow saves them as one 20-second video.

Review each chunk

Set Run to Review Each Chunk and press Queue. After Chunk 1 finishes:

Click Use it and continue.

Press ComfyUI’s Queue/Run button again.

Chunk 2 will be generated as a continuation of the accepted Chunk 1.

You can also select Use it and finish the rest after reviewing Chunk 1.

If the two 10-second videos were already generated as completely separate runs, Continuum cannot retroactively make their visual content continuous. You can concatenate them in a video editor, but that only joins the files and does not create a seamless transition. To obtain real continuation conditioning, generate both chunks inside the same Continuum run.

If you meant that you want to continue from an already exported external video, that is a different procedure and is less seamless because the original raw continuation latent is no longer available.

@jth3gravedigger625 Thanks for following up! By “the same run,” I mean the same saved Continuum sequence—not necessarily a single press of Queue.

You don’t need to add a Last Frame for the first chunk or change the references afterward. Last Frame is the target for the end of the whole sequence, not a marker for where each chunk ends.

With saved Progress enabled, Continuum reuses its stored chunk data when you continue; it does not automatically reload the exported MP4. Uploading that MP4 as a Video Guide is a different operation, not the same as resuming saved progress.

However, V3.8 currently has reported bugs affecting Review mode and saved settings, and I’m preparing a hotfix. The steps I described may therefore not work reliably in your current installation—sorry for the confusion. I recommend waiting for the hotfix before relying on the step-by-step continuation workflow.

Thanks for the feedback. Could you share a link or the name of the other Ref2V workflow where your prompts work well, along with the prompt and Continuum settings you used?

Comparing the two would help me understand what’s different, especially how the instructions are assigned to each chunk. I don’t want to assume this is a prompting mistake. Examples for different generation modes are also a helpful suggestion—thank you.

@oldthrashbar Thanks, this is actually a very useful observation.

Changing Chunk 2 / (continuation) to something more explicit like Chunk 2 / (continuation of Chunk 1) makes sense. With List prompts, that wording is part of the actual prompt sent to H3, so it may help the model understand that the next section is a direct continuation rather than a newly established scene.

It does not change Continuum's underlying latent continuation mechanism, but it can improve the semantic continuity of the prompt. I may incorporate wording like this into the recommended prompt examples.

One important detail: if you use Timeline format, keep the header itself as [Chunk 2]. Continuum treats that as parser syntax. Put the continuation instruction inside the section instead, for example:

[Chunk 2]
Continuation of Chunk 1. The same action continues naturally from the previous moment...

Your other observation about H3 responding well to more descriptive prompts also matches what I have been seeing. I would not necessarily say “longer is always better,” but H3 generally seems to benefit from clear descriptions of subject state, action, camera movement, environment, and continuity instead of very short tag-style prompting.

For the Ref2V replacement prompt, the repeated instructions such as “everything else remains exactly the same” and “frame-for-frame” may actually be pushing the source video too strongly. That could be one reason it sometimes reproduces almost the original video and only makes a smaller change such as clothing. I would try slightly reducing those absolute preservation instructions while making the desired identity replacement more explicit.

And yes, V3.8's chunk review/reroll should be useful for exactly this kind of experimentation once the memory issue on your setup is resolved. Thanks for sharing the results — the continuation of Chunk 1 wording is particularly interesting.

Thanks for the update! I’m glad V3.8 is producing seamless 30-second results in your other ComfyUI installation, and that you were able to roll back your original setup.

That comparison is really helpful. It’s too early to tell which update made the difference, but please let me know if the transitions or character morphing return. Thanks again for testing and sharing your results!

Hi @hatt2, thanks for reporting these!

#1 — Reference audio assignment:
In the code I reviewed, I couldn't find anything that swaps Reference Audio 1 and 2. However, I haven't reproduced this with an actual audio-generation test, so I can't rule out a bug.

Subject numbers don't automatically determine audio assignments. Please explicitly specify which person should use <Audio 1> and <Audio 2> in your prompt.

Could you share your workflow JSON, prompt, model name, and whether the swap happens from the first chunk or only in later chunks?

#2 — External chunk controls:
Implemented and pushed to GitHub main. After updating, you can connect an INT node to Chunks and a FLOAT node to Seconds per Chunk, as shown in the attached image.