Editing and merging casts

[mholt]

Hey, really loving asciinema. Thanks for making such a simple and elegant tool. I'm using it to record a demo of Caddy to appear at the top of our new website.

I'm now editing the casts in "post" and fixing typos is pretty easy, but combining two casts that I had to split up is not so easy because of the absolute timestamps on each row.

The cast file format is really great for manual editing except for that timestamp... if it was relative to the previous one, I feel like that might be easier to work with, since any chunk of a cast instantly becomes portable.

But in my case I have to insert part of a cast at 24s that in the other cast starts at 19s. To properly do this, I need to shift all the timestamps of every row starting at the inserted chunk. If the timestamps were relative, no adjustments would have to be made.

Does that make sense? It's probably too late to change things, but one question I had was if you know of any existing tools for editing casts that could make this easier?

Thanks!

[ku1ik]

There are pros/cons of having absolute timestamps vs deltas (we used to have deltas in v1). For the manual editing the absolutes are a con for sure. I'd like to solve this (or at least make it easier) in 3.0 of the CLI, which I'm working on now. Happy to hear any ideas, both for potential changes to the asciicast format and to the CLI, that could improve this usecase.

Meanwhile, check this list of integrations built by the community: https://docs.asciinema.org/integrations/ (btw, this is the new docs site)
There are few tools there that may be of use to you.

[mholt]

@ku1ik That's awesome, thanks.

I didn't know you used to use deltas; I guess I am unfamiliar with the reasons for switching, but I'm sure they were good ones.

I have no idea the implications here, without knowing the background, but I wonder if each row in the recording can have either absolute or relative, or potentially even both?? Relative if it starts with + or -, otherwise absolute. I dunno.

Maybe a better solution would be for the player to also have an edit mode. You could pause it and mark bounds and then choose to speed them up, slow them down, cut, etc, like a frame-by-frame step capability.

As I think about this more, if editing is built into the player, the need for relative timestamps basically goes away, since I don't need to hand-edit the casts anymore.

[ku1ik]

Adding editing to the player would be a major endeavor, and almost exclusively frontend/UX work, so not looking forward to it at the moment :)

But having an easy to use asciinema edit demo.cast command is something I'd like to add to the CLI soon. One idea I had for it is to launch $EDITOR with adjusted recording (via tmp file) for easy editing, with relative timestamps, maybe additionally annotated with absolute ones in human format for convenience / easier navigation. Once you save and quit the editor it rewrites the timestamps back to the absolute ones.

The augmented file opened in the editor could only slightly resemble the asciicast format, and be focused on being human friendly. Quick example I just came up with:

WINDOW=80x24
SHELL=/bin/bash
TERM=xterm256-color

# 00:01.00
1.000123    o foo\r\nbar
# 00:01.50
0.500000    o bar
# 00:01.80
0.300001    i \n
# 00:04.34
2.543210    o baz
# 00:04.68
0.339000    o qux

Re having either abs or rel timestamps supported in the file: it seems nice from the editing POV but it would add a bit of complexity to all the tooling, and there's quite a bit of it out there. I admit I had this idea as well (e.g. specify timestamp mode in the header line), but I'm not sure if worth it. I'd rather have one canonical way of specifying time in the file format, but implement functionality (such as edit command) on top of it.

Using a new, version 3, of the asciicast format with the upcoming CLI 3.0 is also on the table, I think. I'll try to compile a list of pros/cons of switching to relative time (deltas) again, and we'll take it from there.

Btw, asciinema cat <filename1> <filename2>... in 3.0 will produce concatenated asciicast output from multiple input cast files, adjusting time values appropriately. This way you can record individual "chapters" separately and concat them together easily. If that'd be any helpful for you, you can use it already by building from source (see https://discourse.asciinema.org/t/testing-the-new-rust-version-of-the-asciinema-cli/778)