Clip Names Corrupted

It seems there’s still a problem with clip names being corrupted. The clips in the screenshots were correctly named when opened (a). I deleted the first two clips (b) and inserted two clips at that point (c). You’ll see the other clip names have been replaced by ‘Music Track n’. This issue has plagued clip names since they were introduced and it’s not worthwhile naming them while it persists.

[Windows 10 Home 21H2, Audacity 3.1.3]
Clip names c.png
Clip names b.png
Clip names a.png

I’ve tried to replicate this on W10 with 3.1.3 using some simpler steps (so that a bug may be logged) - but I can’t reproduce this.

@Bran Smith: any chance you can reproduce this with a simpler scenario (fewer clips, single track) with detailed steps to reproduce, to make this happen please?

You say that you " inserted two clips at that point (c)" - exactly how did you do that please?


@Peter: I’ll do ask you ask but I have a lot of shows to record, so it’ll be later this week.

I double-clicked on ‘Winter Wonder’ to select, then F9 to add the short clip before it. I deleted them, then selected ‘Ding Dong, Ding Dong’ and the short clip before that from another project, then inserted them at the cursor point. That’s when the clip names were corrupted. I’ll try moving clips separately to see whether that affects the issue.


Thanks Brian - that’s fine as I’m a bit busy this week anyway.

But it would be good to get to the bottom of this. If we can find some simple steps I can post a GitHub issue for Muse to look at and hopefully fix.


Found it - the issue occurs when moving multiple clips, which wrecks the names of subsequent clips. When they’re moved separately the names are preserved. The obvious solution is to move them separately but it’s worth investigation and correction.

Hi Brian, I still can’t reproduce this.

My steps

  1. created a chirp
  2. moved it along the timeline to create some space
  3. split it into four clips
  4. Labelled the clips: 1, 2, 3 & 4
  5. Selected clips 3 & 4
  6. dragged into the space created on step 2
  7. Observe all looks fine
    dragged clips.png
    I can drag the 3&4 clips back ad forth and all remains fine :confused:


Hmm, that’s computers for you! I now know what not to do so I suggest we let it rest. Thanks for your time, Peter.

@Peter: I noticed you were working within the same track. My clips were moved from another project, perhaps the answer lies therein. It’s not my place to tell the developers their job but I would investigate the code where clip names are entered, which seem to be based on the track name. If a clip name has a null value then enter a generated name; if it already has a value then leave it. Once a programmer… :slight_smile:

OK I’ll try some more testing - this is fascinating me.

One learning I’ve made from this is that it’s possible to select multiple clips and move them around in sync with the grab-handle drag-bars - cool.

Me too… but that was half a career and a longish retirement ago (Fortran IV and the odd bit of assembler was in my toolbag back then) :nerd:

@Peter: I also discovered by accident that multiple clips can be moved - very useful! Further use since my last comment shows the same results when moving or copying clips, single or multiple, from one project to another. That’s select, copy or cut from one project, paste at a cursor in another.

Post-release bugs sometimes arose from the way people used (or misused) the system - ways that weren’t contemplated in the specification or design. A colleague used to say “that’s not a bug - it’s a feature!”, and sometimes got away with it. :smiley:

Hi Brian,

well I’ve tried copying and pasting single and multiple clips from one project to another back and forth - and I still can’t get any clip-label corruption

That’s users for you - they will go and use (and bend) systems in ways you never thought of as a designer/developer, that a;ways used to amaze me

I heard that many times in Audacity over the years when I was working on the QA testing and logged bugs in the old Bugzilla bug-tracker. And that could lead to some “spirited” discussions.

If you want to see some “features” of Audacity that I’ve long campaigned against, take a look at the bear-traps page in the Audacity Wiki:‘Stuck_In_a_Mode’



a search through Muse’s bugtracker on GitHub shows this bug that Steve logged a while back:

Clip names lost when pasting between projects #2196

Sound familiar ?

BTW if you want to see the full list of Clips bugs that are logged and open, have a look here:


@Peter: That’s quite a litany! As far as I’m concerned looping is a feature too far (and caused me continual annoyance before 3.1.3) but it could be the answer to another user’s prayer.

The fact that we’re getting different results from apparently the same actions makes me wonder whether it’s the way I operate. We learn most software by trial and error, when all else fails we RTFM (read the flippin’ manual). :smiley: Remote support often obscures things that being on-site makes immediately apparent. Clip names are relatively new; I did without them for years and would never have thought of requesting them.

I’m enjoying this exchange but am conscious of taking up a lot of your time. When 3.1.3 becomes more widely used others might experience the issue. I’ll keep at it and will report if I uncover the reason.


@Peter: I missed your most recent post while I was writing mine, relieved to see it’s a known issue and logged. I’d been getting that “is it me?” feeling. :slight_smile: I imagine it’ll take its turn and be fixed in the course of time. Many thanks for your input, wishing you a safe and happy 2022!


Hi Brian,

I have added a “nudge” to the bug thread to try get get it’s priority raised a bit and to try to gain it visibility for inclusion in the list of bugs to be addressed for 3.2.0.

Clip names lost when pasting between projects #2196:

3.2 backlog tracking #2353:


Thank you Peter. :slight_smile: