Volume Analyzing bug in CD ripping

[dip]

I have in MM3.2 the option "automatically analyze volume for not analyzed tracks" set and have the following problems with ripping CDs. (Note: I have NOT checked the option to adjust the volume in the ripping dialog)

1. During ripping a CD MM starts to analyze the volume immediately after the first track has been ripped. During ripping the remaining tracks of the CD MM several times starts to reanalyze the volume of ALL tracks that means it restarts analyzation from track 1 several times. That results that for a CD with e.g. 10 tracks in the status bar is says "analyzing x of 38" (or even more) since after having finished ripping, a track analyzation for all already analyzed tracks is requeued. This reduces ripping speed drastically. In my opinion analyzation should only start after the complete CD has been ripped.

2. Before starting ripping a CD I sometimes amend the tags received from freedb (especially for classical music). As long as I amend the tags using MM's property dialog everything is fine. However, when I amend the tags through a script (e.g. RegExp find & replace) BEFORE I start ripping, I have the following two problems:

First, MM writes an exclamation mark (!) in the track and in the volume analysis columns (that is BEFORE ripping is started but AFTER the tags have been amende through the script). When I then start ripping the volume of the tracks is not analyzed and I must start analyzation manually after having ripped all tracks. When I don't start analyzation manually only distortion is heard when the tracks are played (since the exclamation mark seems to indicate a blasting of the volume).

Second, after ripping is completed not only the ripped tracks but also the original *.cda tracks of the CD have been taken into MM's database. I have then always to delete the *.cda entries (which are greyed out after removing the CD from the tray) manually. This is annoying since the *.cda files should not be taken into the database.

[dip]

No comment? Does nobody analyze the tracks during ripping?

Is the described problem a common problem or specific for my configuration? I forgot to mention that I rip to flac format.

I would really appreciate any comment, since the repeated analyzation slows down ripping drastically.

[Teknojnky]

this has been an issue since the auto-analyze option was introduced.

there is currently no solution other than to disable the auto-analyze option if your going to be ripping cd's, then re-enable it afterwards.

Personally, for this exact reason (and when adding tracks to the library via add/rescan or monitor folder), I only enable the auto-analyze every once in awhile when I want to make sure I did not miss analyzing.

[dip]

If this is an already known long-time issue, has there already an official bug report been filed in Mantis?

If you use volume analysation this is really a critical bug which makes ripping in MM almost worthless. I cannot explain my wife and my childern that they have to deactivate and reactive automatic volume analysation before and after ripping a CD. I know that it will be forgotten to reactivate which will result in a lot of not analysed tracks.

Is there a way to file an official bug report in Mantis?

[nohitter151]

Is there a way to file an official bug report in Mantis?

I'd be happy to get this into Mantis, but I'm not sure I understand the issue. Typically I don't rip with MM so that could be part of the issue. I do, however, have the automatic volume analysation enabled and I often rip my tracks into a 'file-monitored' folder. Indeed the tracks are analyzed one by one, and each time a new track is ripped the whole album is re-analyzed. But that is the issue with that? I have never seen the process fail or anything like that. Sure, the scanning does seem a bit needless, but at least it is automatic. Am I missing something?

[dip]

In my starting post I described three different "bugs" (or problems):

1. The first is that during ripping each time a track is ripped ALL songs are requeued for analysis and so the whole album is analysed several times. While the end result is correct, the problem is that the ripping process in MM is drastically slowed down due to the parallel volume analysis. So in my opinion analysis should only be started after the ripping process is completed.

2. The other two bugs are described in detail under section 2. "First..." and "Second..." in my first post. They are also related to volume analysis during ripping but are not related to the above mentioned first "bug". Are these further two bugs understandable or do you need more explanation?

[nohitter151]

In my starting post I described three different "bugs" (or problems):

1. The first is that during ripping each time a track is ripped ALL songs are requeued for analysis and so the whole album is analysed several times. While the end result is correct, the problem is that the ripping process in MM is drastically slowed down due to the parallel volume analysis. So in my opinion analysis should only be started after the ripping process is completed.

2. The other two bugs are described in detail under section 2. "First..." and "Second..." in my first post. They are also related to volume analysis during ripping but are not related to the above mentioned first "bug". Are these further two bugs understandable or do you need more explanation?

1. If you don't want every track reanalyzed, you could just disable automatic analysis for "Album gain".

2. I understand but I haven't taken the time to reproduce it yet.

[dip]

1. If you don't want every track reanalyzed, you could just disable automatic analysis for "Album gain".

This sounds like a bad workaround rather than a solution and is not really an option since I need album gain. And if I totally disable automatic analysis then you can be sure that my kids or my wife (and maybe sometimes even I) don't think to start a manual analysis after ripping has been finished.

[Teknojnky]

http://www.ventismedia.com/mantis/view.php?id=5533

http://www.mediamonkey.com/forum/viewto ... =6&t=38458

the only other thing you can do is wait patiently.

[dip]

Thanks for letting me know that the first bug is already officially registered in Mantis. Although it is proposed to be solved for 3.1 and jiri commented that there should be an easy SQL implementation it is sill not fixed (and we have already MM3.2).

I hope we do not need too much patience.

Isn't there a possibilty to search Mantis? I did not find any and would like to see if my second bug(s) have also already reported.

[Teknojnky]

Isn't there a possibilty to search Mantis? I did not find any and would like to see if my second bug(s) have also already reported.

sure, just click view issues then look for the search box and apply filter button