Alembic file not recognizing custom start frame when merged (Max 2026 and 2027)

[brittnell]

Is this a bug, or am I doing something wrong?

I've got an Alembic object with "Custom Start" set to frame 0 that is working well. However, when I try to merge it into another scene, the object's animation reverts back to its original frame range, despite "Playback Type" still showing as set to "Custom Start" and frame 0 at it's root. 

I've tried merging into both 2026 and 2027, and the issue persists across both. 

I have work-arounds for the project in mind, but would love some validation that I'm not just doing something wrong or have missed something. 

Thanks

Edit: Realized I needed to also include the alembic file along with the Max file in order for it to work for y'all. 
I created a whole new scene this time, exporting out a sphere with noise animation on it to a Alembic file with a custom range (900-1100). Imported that in, and changed the start frame to 0, which worked fine. Saved that max file and then merged the alembic file into a new scene. The object still says it's got a custom start of frame 0, but the actual animation has reverted to starting at 900 again.

Including files for both Max 2025 and 2026. 

[brittnell]

Ok, after some more testing I'm thinking this must be a bug?

I imported an Alembic object. Copied and also instanced it. Changed the Playback type from "Original Range" to "Custom Start".

The instanced version kept the "Custom Start", but the Copied did not (as expected), HOWEVER, if I now copy the original object with the "Custom Start", the object does not inherit that Custom Start, even though it appears to still have the same at its object root (see attached video). 

It seems this same inability to retain the correct Custom Start frame is also occurring during file merge operations. 

This is making it challenging to work on a base model (texturing, for example) with the intent of then merging it into a scene for use. Scattering the object as copies, with the intent of making further start frame adjustments to individuals becomes problematic as the user now has to factor in the new "baked in" frame offset that occurs on copied objects.