Print

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

[Ripper]

After reformatting the hard drive containing my music, I reinstalled MC12.  Then, I ripped perhaps a couple of dozen new CDs using another program.  Next, I activated MC12's Autoimport feature, checking off the options for thumbnails and perhaps a few other options.  (I don't recall exactly, though I did not check "Analyze sound.")  When I told MC12 to import now, it imported around 150 or so CDs, I think.  Within MC12, I activated an option to get cover art automatically.  Everything seemed O.K.  Then, I closed MC12, and the program produced a "Please Wait: Saving Tag Changes" dialog, counting down from, I think, somewhere in the 9000s.  Since the countdown was proceeding so slowly, I left the room and went to bed.  Today, the next morning, MC12 is still counting down.  It is now at 6,835 tag changes remaining.

Is something going wrong?  At this pace, it could take a couple of days to finish.  I am not exactly sure what MC12 is doing, but I am afraid to interrupt.  I have around 900 GB of FLAC files, so I imagine that it is doing something to them.  But what could it be doing that is taking so long?  I believe that, when I told MC12 to look up cover art, it retrieved around 30,000 of something--of what I am not sure since I don't have 30,000 albums (more like 2,500).  Please help.  Thanks.

[Alex B]

Oops, did you have the "store in tags" cover art option enabled? (Probably, I think.)

If yes, you are doing a complete rewrite of your 900 GB FLAC archive. The fact that tags are stored in the beginning of a FLAC file can make things very slow. MC needs to rewrite the complete FLAC files in case the amount of padding is not big enough. (Padding area is an empty space that is reserved for tags. Usually the padding amount is a only a few KBs. Padding can also be completely disabled depending on the used encoding options.)

This rewriting happens in small chunks, one file at a time. I hope you have some spare hard disk space because each file will became somewhat bigger (by the size of the cover art file). The process will also lead to considerable amount of file fragmentation.

Even if the cover art files are set to be external adding or changing cover art invokes a file tag update. This is by design because the developers needed to avoid a situation in which embedded cover art would not be correctly removed when a new cover art fie is set to be external only. If the files have some free padding area this should be considerably faster than embedding images, but it can still take a long time, especially if the files are accessed through LAN.

[Ripper]

    I must have chosen "Store in tags."  At least the countdown is down to 2,760.  As you had feared, however, the 900 GB of files have swelled to nearly 1 TB.  I do have enough disk space to accommodate this process, it appears, but I am concerned about how I am going to back up this behemoth onto my 1-TB backup drive.  I suppose that I could try to compress it on the backup volume, as I am using the lowest-compression/highest-speed FLAC setting.

    But let me ask you this: what is the point of embedding all the FLAC files with cover art?  Is there an advantage?  If I do not embed, does MC12 store the same information somewhere else?  Can I unembed?  (I am a bit concerned, with all the work that that it took to rip these CDs, that somehow padding the FLAC files might corrupt some of them.)  This is all quite scary. 

    And what of the fragmentation that you mention?  Is it feasible to defragment 1 TB+ of FLAC files?  Would I want to do so?

    Thanks for all your help.

Oops, did you have the "store in tags" cover art option enabled? (Probably, I think.)

If yes, you are doing a complete rewrite of your 900 GB FLAC archive. The fact that tags are stored in the beginning of a FLAC file can make things very slow. MC needs to rewrite the complete FLAC files in case the amount of padding is not big enough. (Padding area is an empty space that is reserved for tags. Usually the padding amount is a only a few KBs. Padding can also be completely disabled depending on the used encoding options.)

This rewriting happens in small chunks, one file at a time. I hope you have some spare hard disk space because each file will became somewhat bigger (by the size of the cover art file). The process will also lead to considerable amount of file fragmentation.

Even if the cover art files are set to be external adding or changing cover art invokes a file tag update. This is by design because the developers needed to avoid a situation in which embedded cover art would not be correctly removed when a new cover art fie is set to be external only. If the files have some free padding area this should be considerably faster than embedding images, but it can still take a long time, especially if the files are accessed through LAN.

[Ripper]

One additional problem: I awoke this mornong to discover that my computer had rebooted itself overnight, displaying error messages sUggesting a crash (although I know that another system had also rebooted overnight to auto-install Microsoft updates).  How can I verify that none of my data corrupted?  Before I went to bed, MC12 was in the 2,000s in updating the tag data, or doing the padding.  This morning, I ran MC12 and ran Auto-update Library.  It began searching my music drive, starting to import 9,000-something files--as I recall, roughly the same number as when I had begun this process the last time.  If I quite the program when it completes the importation, will MC12 again begin the slow padding process?

I don't mind if it takes a few days as long as I do not lose data or have any of it corrupted.

[Alex B]

I must have chosen "Store in tags."  At least the countdown is down to 2,760.  As you had feared, however, the 900 GB of files have swelled to nearly 1 TB.  I do have enough disk space to accommodate this process, it appears, but I am concerned about how I am going to back up this behemoth onto my 1-TB backup drive.  I suppose that I could try to compress it on the backup volume, as I am using the lowest-compression/highest-speed FLAC setting.

It should not consume anything like 100 GB. For example, 30000 x 50 KB is about 1.5 GB. The cover art file sizes can vary a lot, but I don't think the average size can be significantly different.

But let me ask you this: what is the point of embedding all the FLAC files with cover art?  Is there an advantage?  If I do not embed, does MC12 store the same information somewhere else?  Can I unembed?

The cover art files are always stored in the defined location. If embedded cover art is used the separate image files are not linked with the library data, but if anything happens to the file tags MC can relink cover art from these files. You can remove the embedded images by selecting the files and doing "right-click > Cover Art > Remove Cover Art". After that you can link the external disk files by "right-click > Cover Art > Quick Find In File / Cover Art directory".

I am a bit concerned, with all the work that that it took to rip these CDs, that somehow padding the FLAC files might corrupt some of them.)  This is all quite scary.  :

You can't add "padding". The so called padding area is created only during encoding by the FLAC encoder. Tagging files should not corrupt files if the programs and HW work normally. Of course, it is good to have at least one full backup set before tagging a complete library of files.

And what of the fragmentation that you mention?  Is it feasible to defragment 1 TB+ of FLAC files?  Would I want to do so?

I would copy the files to a new empty backup drive and after that clear the source drive and copy the files back. This would consolidate the fragmented files and probably be faster than defragmenting 900 GB of files. In addition, I would automatically get a new backup archive.

One additional problem: I awoke this mornong to discover that my computer had rebooted itself overnight, displaying error messages sUggesting a crash (although I know that another system had also rebooted overnight to auto-install Microsoft updates).  How can I verify that none of my data corrupted?  Before I went to bed, MC12 was in the 2,000s in updating the tag data, or doing the padding.  This morning, I ran MC12 and ran Auto-update Library.  It began searching my music drive, starting to import 9,000-something files--as I recall, roughly the same number as when I had begun this process the last time.  If I quite the program when it completes the importation, will MC12 again begin the slow padding process?

I don't mind if it takes a few days as long as I do not lose data or have any of it corrupted.

It's difficult to answer this. I don't think the FLAC files can be corrupted because of a crash -- or if that can happen only one or very few files can be affected.

The library has probably lost unsaved information like you explained.

Personally I would Import the folders in small patches. Perhaps you could first import the folders that begin with the letter A, then B and so on.

[hit_ny]

If the file system used was NTFS, which i suspect it is, then the chances of file corruption will be much lower.

If you still want to know, i wonder if there is an external app that can inspect the checksum stored in the FLAC file and produce a report ?

[Ripper]

Thanks for the thorough response.  After MC12 finished importing just now, I quit the program, and it did not attempt to pad any files.  How can I be sure that, when the computer rebooted itself last night, it had already completed the padding?  Is it possible to verify the integrity of my music files?  (My music folder is now 1.01 TB.)

Thanks again.

[Alex B]

How can I be sure that, when the computer rebooted itself last night, it had already completed the padding?  Is it possible to verify the integrity of my music files?

You could analyze the files. If you set the input plug-in to not decode through errors the analyzer will stop on a file error.
Tools > Plug-in Manager > Input > FLAC Plugin > Configure > Decode Through Errors (untick this)

If you don't want to change the tags once again you can disable tag writing in the general options.
Tools > Options > General > Importing & Tagging > Update tags when file info changes (untick this)

[Ripper]

    Alex, will setting the input plug in not to decode through errors check all the existing FLAC files, or will it do so only in the future?  I would like to check the existing FLAC files for errors.   Thanks again for your help.

You could analyze the files. If you set the input plug-in to not decode through errors the analyzer will stop on a file error.
Tools > Plug-in Manager > Input > FLAC Plugin > Configure > Decode Through Errors (untick this)

If you don't want to change the tags once again you can disable tag writing in the general options.
Tools > Options > General > Importing & Tagging > Update tags when file info changes (untick this)

[Alex B]

    Alex, will setting the input plug in not to decode through errors check all the existing FLAC files, or will it do so only in the future?  I would like to check the existing FLAC files for errors.   Thanks again for your help.

The setting will make the decoder to stop on an error. When you run the analyzer it decodes the complete files and will stop on the first error. If the files don't have problems the analyzer doesn't stop prematurely.

Select a bunch of files > right-click > Library Tools > Analyze Audio

The tool is for calculating replay gain info, but because it decodes the files it can be used also for verifying integrity. If the files are already analyzed you need the untick the "Skip analyzed files" option.

[Ripper]

Can I get it to analyze all 1 TB of files?  If it stops when it hits the first error, how can I make it verify the rest of the files wthout interrupted?  Finally, will using the analyze option alter data or just analyze it.  (I am trying to output my music without any alteration from software.)

Thanks.

The setting will make the decoder to stop on an error. When you run the analyzer it decodes the complete files and will stop on the first error. If the files don't have problems the analyzer doesn't stop prematurely.

Select a bunch of files > right-click > Library Tools > Analyze Audio

The tool is for calculating replay gain info, but because it decodes the files it can be used also  for verifying integrity. If the files are already analyzed you need the untick the "Skip analyzed files" option.

[Alex B]

You may want to do it in small batches. Select a bunch of albums at a time. The analyzer does not alter the audio data. It measures the peak and average volume levels and calculates the BPM value. This information is normally stored in the library and in the file tags, but as I explained, you can disable tag writing if preferred.

Here is a zip package of two small FLAC samples that you can use for testing the procedure: voice.zip One of the files has an error (I edited it with a hexeditor). Drag the sample files to Playing Now, add a few of your own FLAC files, select the files and run the analyzer. Try both decoding options.