Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mimizone]

I ran into 2 little problems when converting files today.

the source are APE files that are entire albums as one file, containing all tracks.
I am converting them to multiple FLAC files, one per track.

In the conversion option, I specify the destination should be the same folder and the source file not be kept.

But somehow, the APE file is actually not deleted at the end of the conversion.


Second problem was that one track title contained a "/" and instead of quoting/modifying that characters and the metadata, the conversion created a folder up to the / and then the rest of the title as the file name.

I am using the version 28.0.79 of MC.

[mimizone]

The exact option in the conversion is "Replace original file on disk and in library".

[marko]

This...

the source are APE files that are entire albums as one file, containing all tracks.

and this...

The exact option in the conversion is "Replace original file on disk and in library".

help to explain problem #1.

With all the tracks of the album in one, single file, MC uses the accompanying .cue file to know where each track begins and ends within that one, large file. These are then shown to you as separate tracks that you can play independently of each other, but there is no actual, separate "file" representing these separate tracks that you see. They are virtual references to ranges of duration within that one single ape file, defined in the matching .cue file. All of that is to say, there is no "original file" on disk to replace. This is to be expected and most likely will not be considered a bug. When the conversion is complete and you are happy, manually delete the single file, and the matching .cue file.

The issue with the forward slash could very well be a bug.
I can't be sure as I use Windows, and don't have any "single file + cue file" files to test with. I did try using a single track with a forward slash added to the name, and then again with a back slash instead, and in both cases, the conversion went as expected.

[syndromeofadown]

the source are APE files that are entire albums as one file, containing all tracks.
I am converting them to multiple FLAC files, one per track.

In the conversion option, I specify the destination should be the same folder and the source file not be kept.

I have been organizing some of music over the last few days using a Windows PC and have noticed the same thing. I was going to make a new post but may as well add it here.

My typical workflow for dealing will CD images is to drag the .cue file into playing now, the tracks show separately, I highlight them and choose convert with options to use same folder and delete original, the end. The original 300-500 MB CD image has always gotten deleted.

Using 28.0.79 and 28.0.80 the image is not being deleted. The ones I just did were from flac to flac. The last time I did similar conversions is probably in March with MC 27 and I am certain the CD images were being deleted then, just like they have always been.


One more thing I will add to this topic that isn't new, is when doing these conversions if the resulting filenames are too long the conversion fails. There is no warning, there just aren't any files made. At minimum a warning would be nice, or the option to truncate the filename could be useful. Currently I move all CD images to the root of the drive for conversions to minimize the length. A workaround could be to enable long filenames but i have not tried it. Sometimes the resulting filenames can be quite unruly like [Artist] - [Year] - [Album] - [some number] - [Country] - [Track #] - [Name].

[mimizone]

Thanks for confirming the issue.

I don't remember having the issues in the past versions as well. But haven't done those conversions for a while, so not really sure when the problem appeared.

[LilyAarseth]

I also noticed that when splitting ape+cue albums into tracks in .flac, the timestamps in the cue isn't followed properly, resulting in cut off beginnings of tracks so badly I started using an external program to do it instead. Thought it was worth mentioning

[mimizone]

 
I didn't verify and trusted MC for a bunch of files in the last few days...
Arrrr

[Outlaw Audio]

I also noticed that when splitting ape+cue albums into tracks in .flac, the timestamps in the cue isn't followed properly, resulting in cut off beginnings of tracks so badly I started using an external program to do it instead. Thought it was worth mentioning

I have this same issue.  It seems to be a progressive creep of time in that the first 3-4 tracks on a CD are fine but towards the end, the skew is upwards of 8-9 seconds.  Its not just JRiver as DBPoweramp has the same issue when working with tracks that are not part of a recognised album.  As expected, the Accu-rip feature fails on the rips as the CRC doesn't agree with anything in their standard CD database.  I believe this is the root cause of the issue as there is no "confirmed times" in a database whereby exact track length is compared to.  I would love to have someone confirm this theory.  Currently, when working with CUE files I open the FLAC portion in an editor and confirm the start and stop times manually editing the CUE file appropriately.  The operation would be so much easier if one of the programs would search for the silence between tracks and set the track end time based on that

Also, when splitting a CUE file is it possible to get the actual separate album's the tracks came from?  Right now  the Album tag is taken from the FILE text in the CUE file which gives all the tracks the same Album name

[JimH]

That sounds like the cue files aren't accurate.

[syndromeofadown]

I also noticed that when splitting ape+cue albums into tracks in .flac, the timestamps in the cue isn't followed properly, resulting in cut off beginnings of tracks so badly I started using an external program to do it instead.

I have never noticed this, but I just did a bunch of flac to flac so I will check those tonight to see if anything weird is going on.
I always save the original CD images in case I find issues in the future, though I never have. This evening I will reconvert some ape to flac from my archive to see if it has any issues.

I would love to have someone confirm this theory.  Currently, when working with CUE files I open the FLAC portion in an editor and confirm the start and stop times manually editing the CUE file appropriately.  The operation would be so much easier if one of the programs would search for the silence between tracks and set the track end time based on that

This sounds like the cue either has errors or is authored in a way you do not like. I think the pregap is added to the end of the previous track, a simple internet search will bring up the standard. I never see a difference between tracks converted from image/cue vs ripping direct from disc.

[syndromeofadown]

I also noticed that when splitting ape+cue albums into tracks in .flac, the timestamps in the cue isn't followed properly, resulting in cut off beginnings of tracks so badly I started using an external program to do it instead.

I just did a few conversions of flac CDimages to flac, and ape CDimages to flac. No issues on any of them. The tracks start and stop exactly where they should.

One more thing I will add to this topic that isn't new, is when doing these conversions if the resulting filenames are too long the conversion fails. There is no warning, there just aren't any files made. At minimum a warning would be nice, or the option to truncate the filename could be useful. Currently I move all CD images to the root of the drive for conversions to minimize the length. A workaround could be to enable long filenames but i have not tried it. Sometimes the resulting filenames can be quite unruly like [Artist] - [Year] - [Album] - [some number] - [Country] - [Track #] - [Name].

MC names the converted tracks "[CDimage filename]  ([Track #] - Name])". So the issue is mostly when the CDimage filename is long to begin with, then when this is added to long names and subfolders the conversion (used to?) fail without notification. I do think the current naming convention does make sense. I just tested some long file names and it appears they no longer fail, they now are named "Temporary Convert File - 2892 (1)". This works for me as the tags are there and the filenames can be easily renamed based on them, but having [track #] - [name] would be preferable.

Sorry to distract from the original post about the original file not being deleted. In my latest tests the original file remained after each conversion when it should have been deleted.

I am using latest windows version. 28.0.80.

[LilyAarseth]

That sounds like the cue files aren't accurate.

When I used medieval cue splitter it worked just fine, but when MC did it, it cut off a lot, same files.

I just did a few conversions of flac CDimages to flac, and ape CDimages to flac. No issues on any of them. The tracks start and stop exactly where they should.

I haven't tested for a while so maybe it is fixed now, I converted all of my .ape rips to flac and stopped using the format entirely

[Outlaw Audio]

When I used medieval cue splitter it worked just fine, but when MC did it, it cut off a lot, same files.

As I suspected, not all CUE splitters are created equal.  Whatever the issue at hand, thanks so much Lily for the recommendation.  medieval cue splitter has worked flawlessly on every cue file I've tried 

[marko]

That used to me my go-to for splitting cues too. Awesome Donkey recommended avoidance, suggesting CUETools would be a better option...

https://yabb.jriver.com/interact/index.php/topic,123101.msg852872.html#msg852872

[Outlaw Audio]

Seems my elation was a bit premature.  The last thirty or so disc images (ISO) that I split into tracks, were skewed as before.  Looks like it was luck that the two images I initially tested on were already correct......onward with the discovery

[syndromeofadown]

Seems my elation was a bit premature.  The last thirty or so disc images (ISO) that I split into tracks, were skewed as before.  Looks like it was luck that the two images I initially tested on were already correct......onward with the discovery

Is the computer you are using to split images extremely old and slow? I ask because the only time I have had an issue encoding audio is with a slow computer where I was multi tasking. This was a very long time ago.

If there is a particular CD Image that doesn't work for you, it may be worthwhile to provide it for someone else to test.

MC is a good choice for splitting CD Images. I don't use MC for splitting files just because I have it, I use it because I think it does the best job, and it is dead simple to use.

[Outlaw Audio]

Actually the platform im using is (was?) a fairly robust machine

• Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz   4.20 GHz
• 32GB DDR4 memory
• 64Bit Windows 10

There's no particular image that this happens on but I'm suspecting that the image creation is the issue.  I'm using Daemon Tools which I've used for quite some time; but may have found an area where this software does not excel

[syndromeofadown]

There's no particular image that this happens on but I'm suspecting that the image creation is the issue.  I'm using Daemon Tools which I've used for quite some time; but may have found an area where this software does not excel

What are you doing with Daemon Tools? Are you mounting the image? If so, you should not. They are not like iso's.
All that is needed is to drag the cue file into playing now, then convert.