I decided to post in the most similar thread to my issue.
My system:
Windows 10
Audacity 2.2.2
Problem – some labels disappear on Labels export – in the file exported only. They remain in Audacity project file.
Use case: I put transcription of audio in the labels. I use Audacity to adjust segments beginning and endings. I want to export the labels to a plain text file. It appears that those labels >255 characters long are dropped from export. For the time being I can workaround by fetching that information from AUP xml. But it seems it is a clear yet small bug.
I’ve split this to a new topic as the issue in that 2014 topic is probably no longer relevant. Generally it is least confusing to start a fresh topic for each issue.
I’ve just tested with the following labels, and the problem does not occur for me.
0.524367 0.524367 a
1.000000 3.000000 123456789112345678921234567893894123456789512345678961234567897123456789812345678991234567890123456789112345678921234567893894123456789512345678961234567897123456789812345678991234567890123456789112345678921234567893894123456789512345678961234567897123456789812345678991234567890
4.250455 4.250455 b
Besides other, it contains a WAV and AUP, TXT files (not) containing (not all) the labels. Also, a screenshot is provided where I mark 3 labels not included in the exported Labels file. The text is >255 chars long.
Also, I provide a manually edited Labels file containing all the labels. This Audacity project can be easily re-created by importing the WAV, the labels file, then re-doing export of labels.
I’d forgotten about this, but this is a known limitation of labels. You were almost correct about a 255 character limit - the limit is 260 characters
I’ll log this as a bug because even though this limit is by design, I think there should at least be a warning that the number of characters has been exceeded rather than silently ignoring them.
I think there are two general use cases (I am aware of currently):
Reuse labels to generate filenames to split audio in smaller pieces and auto-generate filenames from text of labels. The said limitation is valid in this use case. Some specific characters should not be allowed or be replaced by substituted/placeholders such as \ : / etc. In fact the limitatiion is in effect only when running the Export / Split methods / actions.
Use labels to annotate audio text. To later export it as TXT labels. No length or repertoire limitations be in effect.
If any limitation has to come in action, cool if a warning came up with an informative Abort / Perform limitations info.
Those are certainly two of the most common uses for labels. How to satisfy both of those requirements simultaneously is the tricky part.
I think that would be an adequate solution, and may be the simplest to implement.
Another possible solution is to allow arbitrary characters / string length, and on export, convert the text to a valid file name, where “conversion” would use character substitution and string truncation. If we go this route and allow strings of any length, and any printable UTF-8 characters, then I think we should also support multi-line text in labels. This option moves more towards a “feature request” rather than just a “bug fix”.
My current bug post is rather about eliminating the bug soon of leaving longer labels out and remaining in the current functionality. A new feature may require longer time to implement rather than having a bug fixed.
Our workflow involves a previous step in text editor, Notepad++ to have the entire text split as we found AC not as handy for managing text eg splitting etc. Those all would be nice features to have but that will take more time to implement. Having multiline labels – there is a risk of turning AC into a text processor which needs to be well balanced.
Yes indeed. Consequently I think that a hard limit on the number of characters (with a warning) is the most likely fix (unless whoever fixes it finds a better solution).
Yes it needs to be balanced, but multi-line labels are already supported in the AUP (XML) format. If you manually edit an AUP file, it is possible to enter multi-line text, and opening the project in Audacity “nearly works” (I’ve only tested on Linux). Example:
We keep using Audacity 2.2.2 as we work with Labels.
Today we discovered another bug in relation with that.
We create a project from a WAV and import Labels from a TXT file. We can edit the labels and save the project. All the labels are saved at the end of the AUP file. Fine that far.
The bug becomes visible next when we open the project again. If the length of any of the labels exceeds ~255…260 characters, those labels are not available in the labels editing pane of Audacity.
