I am trying to export a CD project (red book, single wav file, with toc and cue files).
It gets to the end of the export, and then crashes. I’ve tried over a dozen times.
In the project’s export folder, the wav seems to have exported fine, but the .cue file is incomplete and there is no .toc (both were selected in the export’s menu for the red book properties).
This is on Xubuntu with Ubuntu Studio package, linux kernel version 5.15.0-91-lowlatency.
The terminal output (which I have to type out from a picture bc the crash takes my mouse and keyboard away so I have to hard shut down the system) are:
Announcement string is too long (probably behind a proxy).
terminate called after throwing an instance of ‘Glib::ConvetError’
Aborted (core dumped)
and then afterwards it has my terminal prompt with:
ardour-request-device: watched PID no longer exists - releasing device.
even though i didn’t type that last part.
any advice on what I may be doing wrong? even if it crashes, but I can get the wav and toc and/or cue files to export correctly, that’s good enough for now.
A gentle reminder for basic rules regarding talking about bugs on the forums (and in the tracker too):
always specify the version of Ardour you’re using that has problems
always specify the platform (OS) you’re using
remember that anything other than the official builds from ardour.org are not formally supported here (though many nice folks may help out)
if you’re not using an official build, fetch a free demo from Download Ardour | Ardour Community and install it in parallel with whatever you are using, and test that.
Sorry, Paul, and understood. I’ve been gone for some time.
The specific linux distro is Ubuntu 20.04.6 LTS. The specific ardour… well, really its Harrison Mixbus 9.2. I thought I would try these forums as I usually get faster responses here. I understand Mixbus is definitely not formally supported here, but I’m hoping on that nice folks part you mentioned
But if I don’t get a solution soon, I think I’m going to have to finish this in Ardour… and then maybe go back to Ardour. Mixbus has been treating me terribly for a while now.
Do some ranges (likely song names) have non ASCII chars? cue/toc is not using UTF-8 but some ISO encoding and it seems that converting umlauts or accents fail.
That is normal when Ardour crashes. There is a watchdog helper tool that releases the soundcard. Ardour itself can no longer do that after it crashed.
Thank you so much Robin. Yes in fact there are musical flat and sharp signs in the song title/region marker names. I’ll try to remove those and see if the export goes well. Now with that said… does that mean there will be no way for me to cue/toc files with those symbols in them? The track titles are “piece in a♭” or “other piece in c♯ dorian”, for example.
A workaround would be to rename the tracks in Ardour to “Piece in aFLAT” and “Piece in cSHARP”, export that and then open the toc/cue files in a text editor and replace FLAT with ♭ and SHARP with ♯
At least as long as the programs using those toc/cue files are OK with the symbols
thank you all for your help. i’ll try that as soon as i get back to the studio tonight. hopefully brasero doesn’t hate the music signs, but if so using “flat” and “sharp” is an acceptable workaround.
thank you all again.
OK, I can partially reproduce this. I get an Error log:
[ERROR]: an error occurred while writing a TOC/CUE file: Cannot convert c♯ dorian to Latin-1 text
but Ardour does not crash here. Odd.
The "TOC file is created, and ♯ is converted to an underscore, but the .cue file fails. I’ve now changed this so that cue files are use an underscore for UTF-8 chars that cannot be converted to Latin-1.
For the “♯” you could use the ASCII hash “#” instead, and well “b” instead of “♭”.
The CD-Text is older than UTF-8, and most CD-players can likely only display ASCII.
understood, thank you for taking the time to try to recreate it.
in general, mixbus crashes a lot for me. i built a box that was spec’d pretty well for my music production, but i still have a lot of trouble with mixbus and the ava plugins. which i know is nobody’s business here, but i am getting pretty tired of it.
So I have noticed specific workflows tend to cause issues more than others. I teach a class on mixing that utilizes Mixbus, and every now and then I have one student that always seems to be great at crashing Mixbus, but have never been able to pin down exactly why. If you haven’t already I would reach out to Mixbus support, especially if you can recreate the crashes reliably and let them know. I would honestly bet that in most cases those same workflows might cause issues in Ardour as well for the record.
I almost forgot you teach in Mixbus. With that said, I do debate that last claim you made. Ardour was never this problematic for me. tbf, it hasn’t been my daily driver since v5 or 6, but I doubt its less reliable now. And my workflow is more or less the same as before I switched to Mixbus.
I’ll try to pay more attention and log outputs from the crashes so I can consult with MB support but the problem seems to be AVA plugins more than anything else. But even the issue I opened this thread for… as Robin says, Ardour doesn’t crash. It simply doesn’t do the impossible task and even gives an error that makes it clear what the problem is. If MB gave that same error, I could have deduced the solution myself.
P.S.- if you do figure out what your student is doing that is exasperating the situation please let me know. If I can figure out the same for myself, I’ll be sure to reach out to you.
