Cue files path

I've found the cue... Although an album was split, a series of cues was created, one cue per track, although was an album of variius artists. It is so wrong. The cue series was created in folders per cue on a path set for some previous batch, although the application was set to use the same path as the input file. This is so unmanageable!

Hi, just had a look at this and found that there is a bug when using the "Use input file folder" option with cue sheets. The cue sheets will still go to the configured output folder instead of the input file folder. This will be fixed in the next release.

Music file references in the cue sheets are relative if possible. But if the cue sheet is in a path unrelated to the music files (like cue sheets being written to ~/Music and tracks written to /media/...), fre:ac resorts to using full paths. In your case, this is likely caused by the aforementioned bug with "Use input file folder".

When dealing with various artists albums, it's important that the album artist is set to "Various Artists" (or some other common album artist). Otherwise fre:ac will treat the tracks like belonging to different albums from different artists and will create one cue sheet per artist/album combination. There is an option on the Playlists page of the configuration dialog to force a single cue sheet per conversion job.

This all applies to the 1.1 alpha version which I assume you're using. fre:ac 1.0.32 has very limited cue sheet and album artist support.

Hi, thanks for the fast reply!
Would you take into account that a common term for "Various Artists" is "VA"?
But even so, "Various Artists" makes a cue per track.
What should the original cue look like?

Regards.

It does not work with "Various Artists" in the "Performer" cue entry. It creates one cue per track.
Indeed, I use alpha since it appeared.

Sorry, didn't get to answering yesterday.

I didn't realize that you were using a cue sheet as input. There are indeed some issues with fre:ac when dealing with multi-artist cue sheets.

The current version ignores the top-level PERFORMER entry instead of using it as the album artist. That's why you're getting multiple cue sheets when trying to split a various artists album. Similarly, when writing cue sheets an album artist known to fre:ac is not written to the top-level PERFORMER entry. Both issues will be fixed with the next update.

If the album artist is "Various Artists" or "VA" or anything else should not matter as long as all tracks have the same album artist. But I now understand that it's the above issues that are holding you back.

Thank you for the fast reply.
I'll wait for the new alpha.

Regards.

I have an update at https://freac.org/updates/freac-1.1-alpha-20190606-x64.zip

For Linux you can use the continuous build: https://github.com/enzo1982/freac/releases/tag/continuous

This should now respect the "Use input file folder" option when creating playlists and cue sheets and add support for album artist in cue sheets (reading and writing).

Would be great if you could give it a try!

Hello, thanks for the fast reaction!
I don't use Windows, so I can't test it there.
On Linux, I have Sabayon, 64 bit, I can't run the AppImage, although I use several apps in this format. I get a ton of "binary operator expected" errors in line 8 for the x86-64 bit one. The 32bit asks for a different version of fuse, probably:

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

I need a regular 64 bit distribution or those above fixed.

Please try the latest continuous build. It should have the "binary operator expected" error fixed and also fix a libcurl linking issue that I found trying to run it on Sabayon..

To run the 32 bit version you'd have to install a 32 bit libfuse and possibly some other 32 bit libraries. Better just go with the x86-64 version.

The cue files are notcreated along with the audio files split or converted.
1. The cue files are created on a path that is different than the resulting audio files. For instance, if the files are created in a path with a pattern, like "<year> - <album>/<track> - <artist> - <title>", the cues are on "<artist> - <album>/<artist> - <album>" path.<br> 2. For variuos artists many cue files are still created in folders , which makes things hard to compile a cue out of them because they are again as "<artist> - <album>/<artist> - <album>". In my case, the path should respect the left part of the path for all the files, audio and cue, which is "<year> - <album>" in my example. Cue file pattern might be useful too. Although I don't make playlists, probably they should obey some pattern too, or the same as cues, although playlists could be done for many folders, so it's not a good idea...</p></title></artist></album></year>

Hi, tried again today, with no success.
Why not make a cue file per cue file source, even for various artists cue?
If not possible to guess, why not add a checkbox for that?