Print

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

[hit_ny]

11.1.173 (4/19/2006)

11. Fixed: Old Cue files were not overwritten even if "overwrite" was enabled by user.

Can anyone explain what "overwrite" here means ?

Is it saving any changes made in the library back to the respective cue file ?

[Alex B]

It is one of the advanced ripping options.

[hit_ny]

If i follow that means you want to replace the previous cue file with one from a recent rip ?

..still confused why this is required.

[Alex B]

I suppose MC's ripping system overwrote the main audio file, but not the cue file when the target files already existed.

When ripping to single file and cue the overwrite option may be useful if you are replacing an old CD with a different remastered CD that may have different track timings and/or bonus tracks. Sometimes even different pressings of the same CD contain slightly different track timings.

[hit_ny]

But then you certainly want to replace the original media file as well right

..since its been remastered.

[Alex B]

If I have understood this correctly MC overwrote only the audio file before this fix. I have never tried to rerip a disc image & cue album and have no idea what MC did with the cue file. Perhaps it made a new cue with (1) in the name.

[Doof]

That's exactly what it did. There was nothing more frustrating than using autorip, popping in a CD and noticing that whoever had originally submitted that CD to YABB had misspelled something, so you cancel the rip, fix the mistake, then start ripping again. Only now you have two cue files, with the new (correct) one with a (1) at the end. Then when you run the MakeAPL utility (because I won't use just the CUE file in MC until they put in some way to save tag changes to the file itself), and now you have two sets of .apl files in your library.

[hit_ny]

Then when you run the MakeAPL utility (because I won't use just the CUE file in MC until they put in some way to save tag changes to the file itself), and now you have two sets of .apl files in your library.

When you say save back, do you mean back to the cue file ? or the APL file.

That would be a nice feature.

[Doof]

Well, I only use APL files because there's no way for MC to save tag data to a CUE file. And I don't trust my library enough to only keep the data there. What if someday I decide MC's no longer for me and I want to move on? Not that I see that happening in the near future

So until then, I use APL files. MC can store tag data in APL files, but it can't create them. So I still have to rely on MAC to do that for me.

So if MC could either find some way to save tag data in a CUE file (or a seperate file entirely that's seperate from the CUE file) or create APL files based on the CUE files it creates, that would be great. Ideally, I'd like them to go the APL route. Those are more universal than putting tag data into a CUE file or into some other file.

And it shouldn't be too hard to do... they got the guy who created APE and APL on their payroll!

[hit_ny]

Well, I only use APL files because there's no way for MC to save tag data to a CUE file. And I don't trust my library enough to only keep the data there. What if someday I decide MC's no longer for me and I want to move on? Not that I see that happening in the near future

mpl ? mpl does not care what format your media is and it saves everything MC knows about it.

If you decide to move on, you would need an app that could import xml, you make xsl and that should be it.

I'm moving towards a system that only keeps data in the library and a mpl file per album. Just wish it was quicker to save to mpl, there are currently quite a few steps to do to get save to mpl to happen. Wish there was a way to automate it, so it was just a button on the toolbar.

This was after reading your post some time back about a hard drive going bad slowly (worse than losing it outright, now you have dirty data but no clue where it is),

..the only way to protect against that is checksums.

[Alex B]

Some of us have been asking if APL playback support could be extended to any compression/file format. The needed playback range technology is already inside MC - cue files can be used with all supported encoding formats.

Some kind of virtual file links have been asked from time to time. An APL system could be the answer. It would be great if MC could make APL files from any selected track or tracks, not just from cue files. Those files could be used as virtual links that can hold individual APE v.2 file tags.

Perhaps this could be added to MC12? Here is my feature request thread from December 2004:

http://yabb.jriver.com/interact/index.php?topic=25087.0

The linked test file package is still online.