Convert label to cue sheet, and cue sheet to label

Compounded by, when I originally wrote it, I really didn’t care about all the oddities. Or anyone else’s needs. I just wanted to make something work for my specific need at the time.

It also didn’t help that I was doing it in a vacuum with zero input or feedback or help… never the best for spitting out better code.

Mea maxima culpa. I have made a mistake in my previous posts regarding the format! Earlier I gave the example of track 02 being 00:22:41:00. But those trailing zeros shouldn’t be there, no milliseconds in the file at all :blush: :blush:

This example is correct:

REM DATE 2021-08-18 04:27 PM
REM RECORDED_BY "rekordbox-dj"
TITLE "My Mix v2"
FILE "My Mixfile.wav" WAVE
		FILE "c:/path/to/artist1-song1.mp3" WAVE
		TITLE "Song One"
		PERFORMER "Artist One"
		INDEX 01 00:00:00
		FILE "c:/path/to/artist2-song2.mp3" WAVE
		TITLE "Song Two"
		PERFORMER "Artist Two"
		INDEX 01 00:22:41
		FILE "c:/path/to/artist3-song3.mp3" WAVE
		TITLE "Song Three"
		PERFORMER "Artist Three"
		INDEX 01 01:08:15

My sincere apologies for the rework I’ve caused.

I would really prefer: $Performer&[" - "]&$Title
Or to stick with the example: Artist One - Song One
(space-dash-space only showing when $Performer AND $title both != empty
And only [filename] when both $Performer AND $title == empty

The “artist - title” format has been a best practice since the early days of WAV and MP3 afaik…

Respectively Great & fine!

Now for a little intermezzo, before I continue… For starters: I really (REALLY) appreciate the effort you’re putting into this! On the other hand, I’m just being blunt in sharing my thoughts and giving feedback (I’m Dutch btw, might explain this attitude :wink:). Anyway, I hope you don’t interpret that as being rude. Just speaking out here, since I’m assuming you’re not clairvoyant. So just to be clear: I don’t expect you to follow any of my wishes or suggestions, feel free to ignore any (if not all of them). I’m just trying to help to define use cases. All your efforts -whether in line with my personal preferences or not- are appreciated anyway!

Imho: ignore them completely. I’d like to explain:
In my case I make a DJ Mix, call for example “Summer vibes” by “DJ Me”.
In this mix I’m using 3 tracks, all different artist,s and track titles (think of songs you have heard on the radio).
In case the metadata was not correct, and performer or title were missing (or empty) in the CUE-sheet, it makes no sense whatsoever to use MY name and title instead. Just leaving those track-level values as is would be more logical.

Configuring the output by means of editing the cue file can get quite tedious. The way I use your tool is:

  1. I have a .cue file
  2. I open this in Notepad++
  3. Copy-paste the contents in your webpage
  4. Convert
  5. Copy-paste it back into a (new blank) file in Notepad++
  6. Save as and give a filename
  7. Import this new file in Audacity

And this for every mix I make. For me the following options would work better:

  • just the label in the format as described above, no configuring at all OR
  • configure by using some checkboxes on the webpage (and even better: with checks that are being remembered for the next visit, probably by using cookies)

And to throw in some other “nice to haves”:

  • A button to upload the source file and/or a button to download the result (for downloading you could use the header tags as the default filename: Performer - Title.LBL.txt or something)
  • I’d strip the path from the file, use just the file name (everything after the latest slash). Makes the label track in Audacity a lot cleaner.
  • Of course the reverse-formatting (back to a cue sheet with both performer and title tags) would be great too.

Btw: Feel free to put some banners on your webpage (and/or a Paypal Donate button), and I’d be happy to promote your page to other DJs who might value it!

No worries on the “language”. I used to work for Royal Dutch Shell. There, I had to work with not only Dutch, but basically a globe’s worth of folks for whom English was a second (or third) language. It’s not just the language that presents challenges, but the cultural differences factor into it as well. So, no worries.

And you’re welcome for the effort. I hadn’t planned to do any more, but as it turns out I needed a side project to give my brain a break from my main project. It’s not vacation, except that it sort of is :slight_smile:

If the INDEX examples are correct, then if they follow the standard they are MINUTES : SECONDS : FRAMES – where FRAMES are 1/75 of a second.

The rest I will look over later when I have more time. In a rush now, but I will get back to it.

Unfortunately, back then I had only just started learning to code (I’ve still not touched Awk :wink:) and not being a user of Cue sheets, I doubt that I could have been much help.

It’ll be interesting to compare the output from your web app with the Nyquist plug-ins when I’ve finished them.

Me too. Catch you later.

If that really is hh:mm:ss then

  1. There’s no way to detect that automatically (the converter would need to either have a “switch”, or you would need to customise the code).
  2. It’s not very accurate :confused:
  3. It’s totally non-standard

I’ve looked in the rekordbox on-line manual and I can’t find any mention of Cue sheets or “.cue” fles. How exactly are you creating the Cue files?

As labels are likely to be used for file names (“Export Multiple”), it’s better to avoid space. While most operating systems support spaces in file names, they can cause problems in some situations, so better to replace spaces with hyphen or underscore. If there’s a likelihood of the files going on-line, file names are better to be all lower case, number, letters, underscore, hyphen (only). For a universally safe file name, “artist_one-song_one” is better than “Artist One - Song one”.

For these reasons, I would prefer the separator between artist and title to be a single underscore: “artist_title”.
If you really want the spaces, you could edit the plug-in.

Admiration for you who have mastered the quote function… me, not so much :slight_smile:

In all my years, I have observed various conventions around audio file naming, some best practices that turn out to be situational, but never an actual standard. Perhaps there are best practices or standards in the realm of this or that app, or this or that discipline, but nothing universal.

The available options to embed in a filename include: album, year, artist, track name, track number, track duration, composer, featured performer, genre, sub-genre, label, etc. And there are all manner of “right ways” to order these, which to include/exclude, punctuation, etc.

In my mind, for these tools, it seems the only real solution would be to provide a means to specify a template for the Audacity label text.

Similarly, to include the path in FILE or not, that is the question. Personally, I prefer the path. Others, only the filename. Again, this is highly dependent on the user and their needs, so it should probably be an option as well.

Top level (or, as it actually works, first) performer and title values being used as defaults when missing elsewhere? Again, an option. It works for me and what I was doing, but not for others and what they might be doing. My current thinking is, this is another option (leave as-is, or use template) and for the second option have a template.

That’s three or maybe four more options, plus resolving any interactions with what’s currently in place. If you code, you know complexity growth is closer to exponential than linear.

I’m not really interested (at least, not at this time) in fleshing out the web interface to provide cookies and file transfers and so forth. That is, in part, because if I needed to do batch processing then I would use a macro tool to automate the grunt work. If using Windows, then something TinyTask, but there are [insert money here] more elegant solutions, too.

For example, if I were doing a large project using either of the web tools, I would open the editor and website, then automate the following:

  • export file
  • switch to editor
  • open file
  • select all + cut
  • switch to web tool
  • insert REM options
  • paste clipboard
  • click convert
  • select all + cut
  • click start over
  • switch to editor
  • select all + paste
  • save file

Ideal? No. Better than manually doing those steps each time? Yes.

If your macro tool supports capturing variables, then the first step would be to prompt for “what’s the file name?” With that in a variable, the export file, open file, save file steps wouldn’t even require a pause for keyboard input.

Anyway, just a suggestion on how one might get some relief now rather than later.

I think I’ll spend a little more time making some REM options and templates. REM is ignored in the CUE standard. And while REM is non-standard for label files, it is also never seen by Audacity – the REMs are added post-export / pre-convert.

The web UI/UX is just a front-end to the actual tools. I never envisioned it being the tool for doing batch conversions. It accepts text and feeds it to the back-end tool, then waits for results and presents them to the user. That is why there are no options at all in the web interface, why it’s a “one file” tool, and one reason (of several) why it’s easier (on me!) to add controls by adding REMs to the input.

Bottom line: I’m more interested in providing the conversion functionality than improving the site UX. Honestly, that’s because I’m not using either tool anymore, so I’m not personally feeling the pain. It is also because, if I needed to do a batch conversion, I would do it on Linux (actual or via WSL) from the shell and use the tool(s) directly. Yes, I know, maybe I should consider releasing the actual tools… :slight_smile:

It’s a knack :smiley:

  1. Click the “Reply” button to open the new message window
  2. If you want to insert the quote into a message that you have already started typing, ensure that the cursor is in the appropriate place in your message.
  3. Scroll the page until you can see the text that you want to quote
  4. Click the ["] quote button in the top right corner of that post

The quote will then appear in the message window like this:

Yes there are domain specific “rules”. For example:

  • For Windows: Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn
  • For Linux (including web servers), you can not use a backslash ("") character.
  • Linux file names are case sensitive, Windows file names are not, macOS may be.
  • The host system must support the character set (Multi-byte characters may fail if the host system does not have the appropriate code page, and you can’t use UTF on a system that does not have UTF support)

For any of my files that “may” become public, I like to play safe. I believe the characters [a to z] [A to Z] [0 to 9] [ - _ ] are universally “safe” (though note the point about case sensitivity, and be careful with the hyphen character on macOS).

I think it’s a matter of how much flexibility you want to provide. Increasing the options has the down side of increasing the complexity of the code (increasing the chance of bugs and possibly more difficult to maintain), and may make the app more complex / complicated to use.
I think it’s worth remembering that Audacity labels can be edited in Audacity, so at worst it’s only a matter of convenience.

:smiley: Yes.

Cool. :sunglasses:

By audio file naming conventions, I was not referring to the OS limitations, but to the various preferences. Such as “Title - Performer” vs “(Track#) Title by Performer” vs “track_song-title-no-spaces_performer-no-space” and on and on. There is no such “standard” or “best practice” EXCEPT in the context of a specific application or work/hobby environment or another such grouping.

In a mixed OS environment, I live by one simple rule: File names consist of ONLY lowercase letters, digits, hyphens, underscores, and a .extension of some kind to classify the file (.txt, .sh, .wav, .whatever) Anything else and you’re just asking for headaches.

But as to what order various naming elements appear? That’s a purely local decision. One man’s “Artist - Title” is another’s “Artist (Year-Album) Title [Rating] {Genre} Track#”. One is no more or less correct except in some (usually arbitrary) context.

Sounds like you know, then, that programming (when there are users and UI/UX involved) is at most 10% solving the actual problem, and at least 90% spent addressing the infinite complexity of humans and their myriad wishes and pronouncements of “how things should/must be”. Regardless of efficiencies, effectiveness, and too often even facts :laughing:

As a back-end developer for most of my career, I am fortunate to be able to spend 90% of my time problem-solving and invest only a little time and effort into addressing the human factors. Getting a computer to work with a computer, or a computer to massage data? SO MUCH EASIER :nerd:

Here’s an updated “Label to Cue” Nyquist plug-in:
LabelsToCue.ny (2.29 KB)
This is a bug fix version that prints the track “TITLE” command correctly.
When installed and enabled, it appears in Audacity’s “Tools” menu.

Here’s a “Cue to Label” plug-in.
CueToLabels.ny (4.97 KB)
When installed and enabled, it appears in Audacity’s “Tools” menu.

Installation instructions for Nyquist plug-ins:

Converting from Cue sheet to labels is complicated by the fact that the cue sheet information depends on the app that created it. There are many variations of the format and no definitive format spec. As grimblefritz has commented, this means that the converter either has to have a large and comprehensive (complicated) user interface, or it has to try to make intelligent decisions about how to interpret the Cue sheet.

The “Cue to Label” plug-in provides a few customisation options.
milesvs may be pleased to note that it includes an option to read the INDEX as hh:mm:ss

The track name is taken from the track’s TITLE value, if it exists.
If there is no track TITLE, it looks for other commands for the title (in order):

  1. track TITLE
  2. track FILE
  3. collection TITLE
  4. collection FILE

The first of these that is found is used as the track’s name.

Note: A quoted empty string (“”) counts as a valid name. This allows the user to create empty labels if they want, by setting the track’s TITLE to “”.

I expecting there may be a few glitches with the naming of labels. Let me know if you find any and I’ll see if they can be fixed.

fyi: going on vacation for (bit over a) week. Will read & reply later!

Well, ofcourse there IS the string ‘REM RECORDED_BY “rekordbox-dj”’ that could be used as switch.

I’ve looked in the rekordbox on-line manual and I can’t find any mention of Cue sheets or “.cue” fles. How exactly are you creating the Cue files?

It is done automagically. You can start a recording (see page 155 of the manual), and when the recording is ended a WAV (or was it MP3?) and cuesheet are being created. The cuesheet contains the META-info from the library, for every track that has been played for at least 60 seconds (if I remember correctly).

Of course. I’m also familiar with Unix (and even DOS :smiley:) and know about the problems with spaces. Underscores will absolutely suffice!

Consider me eternally grateful! :smiley:

I don’t have a project at hand atm, but I’ll give it all a thorough test with my next project (in a couple of weeks).

I noticed a strange behaviour when converting from label to cue. The current version of label2cue from gimblefritz (http://grimblefritz dot com/audacity/lbl2cue.php) omit the lowercase letter c in the title when converting. So “chance” becomes “hane”, “picture” becomes “piture” and so on … and it’s only with the lowercase letter c, capital letter C is ok, as is every other lowercase letter.

See the files attached: look at track 4, 8, 10, 18 and 22.

Otherwise I find it a great tool !
Exemple.cue.txt (2.38 KB)
Exemple.txt (719 Bytes)

The aforementioned files

I use macOS Big Sur with Safari, but it has the same behaviour on Windows 10 with Edge browser.
Exemple.cue.txt (2.38 KB)
Exemple.txt (719 Bytes)

Well… it seems that bug has been there since Day 1!

Thanks for the report.


Hey you’re damned quick!
Thank you !

It’s a great tool for those of us who edit audio into track!

Glad to know there are those who get use out of it.