Generate Cuesheet Plugin

MusicBrainz Picard
1

I’ve trying out the Generate Cuesheet Plugin.

Does anyone have any experience of using it?

  • it overwrites the existing .cue file which means some information such INDEX and ISRC is lost
  • I tried it on a folder of individual .wav files, and it generate INDEX values that were not recognised by Cuetools - the values were not 00:00:00, but rather the cumulative length of the tracks to that point. Slightly off versus the actual index values from the cue file
  • on a folder with a single large .wav file (the whole CD) it forgot to include the file name!

Anyone know of something that reads the existing .cue file and adds to it?

Thanks
D

1 Like
2

That’s the only cuesheet plugin, so the alternatives are utilities that are independent of Picard. Maybe I was doing something wrong, but I’ve never gotten the plugin to work the way I expected, either.

The issues you describe sound like significant bugs and missing features. It would be nice to have a more robust cuesheet plugin. I had given up on it trying to use the plugin long ago, but today I looked at the source file for the first time. It’s not a lot of code, but it’s totally uncommented, and could do with some tidying. Some cleanup would make debugging and improvements a lot easier.

1 Like
3

I’ll add it to my ‘to-do’ list. My use case is to update an existing CUE file, not create one. What’s yours?

Mine would use information in the existing file to find a release, then add the MUSICBRAINZ_TRACK_ID and MUSICBRAINZ_TRACK_ID as REM lines to each TRACK entry, preserving any existing info such as Composer, ISRC etc

You might wonder why…the cue file is the start of my toolchain to encode and I want a way to annotate as much at the start so I dont have to do it each time I run a big encode job. Doesn’t happen often, but when there’s a new release of an encoder…

Anyone know why the long MUSICBRAINZ_TRACK_ID name was picked? MBTRK_ID seems easier to handle…

1 Like
4

People need to lose their fascination with cuesheets. They serve a purpose and the storage of metadata is not it.

Split the files, throw the cuesheets away and tag your files like a normal human being.

5

What’s your solution / proposal to the fact that if I re-encode the files, I loose the tagging. I then have to retag each CD and its tracks. None trivial with 500+ cds. Then multiply by 3 formats.

cue files allow me to store sufficient tags and then re-encode. If there’s an alternative, please let me know.

Don’t say, don’t re-encode as things change. new versions of encoders arrive (LAME) and my needs also change.

1 Like
7

If you want to reencode your files (to lossy formats) in the future and keep their metadata stored with the master files, I would recommend to use a lossless format that is taggable. WAVE files with tags or your approach using Cuesheets may work to a certain extent, but this is an old format with many known limitations and/or low support (as you already experienced).

Personally I use tagged FLAC files in my master library and transcode them to lossy formats like MP3 or OPUS for my portable devices whenever I need them (using FFmpeg which copies most of the tags by default).
This could be done every time a new version of the encoder is available without losing quality over the iterations, although I haven’t seen the need to do that so far – encoders don’t evolve as much as they did in the early days of MP3.

4 Likes
8

Marc2k3

Your responses, especially the second one are offensive and unhelpful.

If you cannot or do not want to help, then I suggest you don’t say anything.

If your views or opinion requires you to insult another person in the conversation, then I suggest you should reflect on your views.

You may wish to consider the polite and helpful response from kellnerd as an example.

2 Likes
9

Kellnerd,

Thank you for your polite and helpful response. It is appreciated.

I will look at the FLAC approach that you suggest.

As a sidenote. I’ve been stuck with the question of what to do for a number of years. Went down a dead-end with EAC and saving the .WAVE files with CUE sheets. Then used a program called cueproc (https://hydrogenaud.io/index.php?topic=49281.0) which defined a number of extra tags using REM. These were then passed to the command line of the encoder to add to the encoded file. So while, not ideal and not widely supported, it worked. As a result, I’m being extra cautious on not going down a second dead-end.

One more question on FLAC, are you able to encoded from one version to another?

As for changes, I agree that encoders are relatively stable. I just want to automate this process once and for all - I have both android and apple to consider and now want two variations of image size in the encoded files due to different resolution displays - phone and tv.

Thanks again for the polite reply

10

My use case is to update an existing CUE file, not create one. What’s yours?

I was trying to create new cuesheets that were compatible with CUETools. It’s been a few years, but I think I ran into the same problem you describe of CUETools refusing to consume the generated cuesheets. One potential problem is that the plugin writes fully qualified pathnames. I updated those before importing into CUETools, but iirc, it still didn’t work.

I wanted to convert DJ mixes to/from monolithic files. DJs sometimes release a mix as a single file, and publish the track times. After adding the tracked mix to MusicBrainz (as a pseudo-release), it becomes possible to create a cuesheet to split a monolithic mix into tracks. Conversely, if I ever had to use a media player that didn’t support gapless playback, I could re-encode a continuous mix as a single file.

Below are a few notes about the issues you mentioned:

the values were not 00:00:00, but rather the cumulative length of the tracks to that point. Slightly off versus the actual index values from the cue file

Isn’'t that normal (and necessary) for cuesheets? But yes, the offsets in a generated file can differ from those in your original cuesheets. It’s not necessarily the result of a code error, but this is where more analysis of the plugin would clarify matters.

on a folder with a single large .wav file (the whole CD) it forgot to include the file name!

I don’t think the plugin supports monolithic files. In any case, if you invoke it from a release with no files attached to it in Picard, it omits the FILE line completely, since it doesn’t know what file(s) the cuesheet is meant for.

it overwrites the existing .cue file which means some information such INDEX and ISRC is lost

Since the plugin generates a new cuesheet, it might help to use a diff tool to merge any ISRCs, comments, pre-gap indices, etc. into the generated file. Meld (Linux, Windows) and WinMerge (Windows) are both free and open-source.

11

As it is a lossless format you can of course decode and reencode the files at any time to update for format changes. But I don’t see a need for this, the file format itself is stable.

Have a look at the changelog, there have been no changes to the actual format since 2007. And even then it were only metadata changes. So if you had a need for the new supported metadata you could have updated your existing files, but if not there is no loss in not updating the files.

1 Like
13

Thank you for the response

14

Isn’'t that normal (and necessary) for cuesheets? But yes, the offsets in a generated file can differ from those in your original cuesheets. It’s not necessarily the result of a code error, but this is where more analysis of the plugin would clarify matters

Cuetools rejected the version of the cue file where the INDEX offset was not 00:00:00 for individual files.

I don’t think the plugin supports monolithic files. In any case, if you invoke it from a release with no files attached to it in Picard, it omits the FILE line completely, since it doesn’t know what file(s) the cuesheet is meant for.

There was only one .WAV file in the folder when I tried it. Interesting that when I tried it on a folder with multple files, I think it found them.

Anyhow, given the feedback on tagging the flac files, I think I will focus on that.

1 Like
15

I think you’ll be happy with the result. It really does make things easier!

1 Like
16

The Flac file format does support embedding a cue sheet in a flac file to give you chapter marks.
I would not recommend it as not all tools support this including picard but it might be good enough depends on your use case.

The best approach is to split into multiple files.
A quick google search suggests there are tools that should be able to do this automatically.
As you are moving from one lossless format to another lossless format is you can split and join files, compress, decompress and end up with the same information you started with.

2 Likes
17

+1 on using .opus format!