Print

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

[lalittle]

I just did some ripping and discovered that the duration being reported by MC of some songs is WAY off.  The songs seem to play okay, and the time reported as they're playing is correct, but the time reported in the Tab Window is incorrect.  For example, with the album I just ripped, track 2 is 2:45, but the duration tag shows 1:01.  On the same album, track 6 is 2:44, but the duration reported by MC is 0:59.  The rest of the songs on the album report the correct times.  Note that I had ripped this album before (on April 23rd), and all the songs reported the correct times in MC.

Please note that I'm comparing the times shown for the new rips to the times shown by MC for the tracks on the CD, and to rips from a few weeks ago off the exact same CD.  Also (once again) the "duration" tag is not agreeing with the time shown at the top of the screen when the song is playing.

I'm not sure if these issues are just "reporting" errors, or if there is a more serious problem here.  My concern is that either way, there appears to be something funky with MC's ripping at the moment.

Thanks,

Larry

[lalittle]

I've had a chance to do further testing, and I've discovered some important patterns to this issue.

First, I tried ripping on another system, and did not get this issue.  On one hand, this would seem to imply that it is a "system" problem, but I still believe that this is an MC issue for the following reasons:

- When I rip to WAV files, all the durations are correctly listed.  It's only when ripping to mp3s that I see this issue (although so far, I've only tried wav and mp3 encodes.)  In other words, this is "encoding" related in some way.  This eliminates this issue being due to some sort of "read" error since if it was a read issue, the status bar would not show the correct length, and the wav files would show the same issue.

- The same two songs give me this issue every time I rip this album -- tracks 2 and 6.  The reported durations, however, are slightly different every time (hovering around 1 minute for these 2:44 and 2:45 minute tracks.)

- If I rip JUST tracks 2 and 6, I do not get this error.  In this case, the reported durations of the 2 tracks are correct.  If I rip tracks 1 and 2, however, track 2 shows the issue.  Similarly, if I rip tracks 5 and 6, track 6 shows the issue.  In other words, it's only when ripping the track BEFORE a "problem" track in the same rip session that the issue occurs.

This issue appears to have started sometime AFTER April 23, but BEFORE June 2nd.  As far as I can see, all my rips done before April 23rd show the correct durations.  I have discovered, however, that all the rips I've done since then (which took place starting on June 2nd) show this error -- I just hadn't noticed it until now.  In each case that the error occurs, the reported time for the track is in the neighborhood of one minute instead of the "correct" length.

At this point, I believe that the fact that I don't see this issue on my other system here is due to the fact that some setting in MC may be different -- I'm just not yet sure what this might be.

Thanks again for any help or ideas on this issue,

Larry

[JimH]

What format are you ripping to?

[lalittle]

Important new information on this:

I discovered that if I did an "update library from tags" on the songs that showed incorrect durations, the reported durations would be corrected.  I also noticed when doing this that the bitrates would ALSO change (which I didn't even know were incorrect.)

I "think" that there is a pattern to the albums that present this problem and the fact that these are albums that I'm re-ripping.

Unfortunately, even after I "fix" the issue by updating the library from the tags, a subsequent re-rip will once again report incorrect durations for the same songs.

I've also noticed some connection between manually changing the "Custom" encode settings and having this issue occur.  I changed the settings to "-V 0 --vbr-new" and the durations were correctly reported.  I'm not sure how all this fits together, but there is definitely "some" sort of bug at the moment.

Thanks again,

Larry

[lalittle]

What format are you ripping to?

When I rip to WAV files, the issue does not occur.  It's when I rip to mp3's that I see this problem.  See the details above for other patterns I've found to this issue.  There is a bug in there somewhere, but I'm having trouble pin-pointing exactly where it's occuring.

Thanks,

Larry

[JimH]

Are you using MC's MP3 encoder?  Same on both PC's?

[lalittle]

Are you using MC's MP3 encoder?  Same on both PC's?

Yes -- I'm using the default MC encoder with the settings as described above.

As far as I can tell so far, MC seems to be "remembering" incorrect values of certain fields in between rips.  For example, when I change the encode settings from "-V 0 --vbr-new" to "-V 1 --vbr-new" (i.e. from 0 to 1) and re-rip, the bitrate still displays as the bitrate I got with the earlier V 0 rip.  When I do an "update library from tags" the bitrate changes to the "correct" value, but the values for both the bitrate and the duration (and possibly other values that I don't know about) are not "updated" when I do a new rip, and in the case of the duration, it is completely incorrect altogether.

It appears that at the moment, I am forced to do an "update library from tags" after every rip if I want to ensure that the values for the fields are correct.  If I re-rip the album -- even if I delete the songs first -- "some" of the values will be incorrect.  I can't yet see a pattern to why some songs are effected and some aren't -- i.e. why it is that on this album, only tracks 2 and 6 show incorrect duration.

The fact that this only seems to happen to "re-rips" however, explains why this didn't happen on the other system -- it was ripped for the first time on that system.

Thanks again,

Larry

[Alex B]

So it seems that MC doesn't always (or correctly) update the format info if a newly ripped MP3 file replaces an existing library file. The -V 1 --vbr-new setting is fine and I don't think it has anything to do with the problem.

I wonder if the Auto-Importer is able to interfere the process in some circumstances.

Possibly JRiver would just need to check that MC always updates the format info after ripping a file.

[lalittle]

The thing that I don't get is why the problem occurs even after deleting the previous files.  You'd think that once you delete the songs, there would be nothing for MC to get "confused" by.

Thanks for the responses.

Larry

[rpalmer68]

So it seems that MC doesn't always (or correctly) update the format info if a newly ripped MP3 file replaces an existing library file. The -V 1 --vbr-new setting is fine and I don't think it has anything to do with the problem.

I wonder if the Auto-Importer is able to interfere the process in some circumstances.

Possibly JRiver would just need to check that MC always updates the format info after ripping a file.

The thing that I don't get is why the problem occurs even after deleting the previous files.  You'd think that once you delete the songs, there would be nothing for MC to get "confused" by.

I think you're on to something here.

I had  a strange problem the other day that I just put down to "one of those wierd ones" but maybe it's related.

I was recording some TV shows with my scheduling software and for some reason MC's auto import wouldn't import the files like it normally does so I could see them in my view scheme.

When I browsed into the directory with the files from the tree browser (inside MC) it showed the files but with incorrect durations and when I tried to play then nothing happened (they did play in MS Media Player an explorer showed correct details).

So I selected Delete and deleted the files from the library but they still wouldn't import properly or play, they only showed up in the tree with incorrect durations again.

I then renamed the files in windows explorer and  then they came into the library correctly and appeared in my view scheme and could be played.

So it's like even though I deleted the files from the library, information was either cached or something as the same incorret information was imported again rather than fresh details when they were reimported.

In case it makes a difference, I had the library open as read only so these files must have been imported/cached locally as they couldn't go into the main library.

Richard

[lalittle]

I just found what I believe to be an important clue in solving this.

I ripped tracks 1 and 2 and confirmed that the duration of track 2 was being incorrectly reported as 0:50 by MC (this song is 2:45.)  I checked the song both in the library, and via the "Drives and Devices" tree.  I then created and switched to a new, "test" library that had NO files imported yet.  I navigated to the encoded tracks via the "Drives and Devices" branch of the MC tree and discovered that the duration of the exact same song/file was CORRECTLY reported by MC as 2:45.

In other words, the SAME file seen by the SAME installation of MC on the SAME system is being shown with the CORRECT duration in one library, but with an INCORRECT duration in another.

I'm not sure what to infer from this, but it strikes me as an imporant clue.

Thanks again for the feedback here,

Larry

[lalittle]

I've been doing more testing on this.  While I have not yet been able to get the new "test" library to produce incorrect duration information yet, I HAVE noticed a similar issue with the reported bitrates being incorrect.  In other words, I rip at VBR "High," and then re-rip at VBR "Extreme."  The bitrates reported by MC continue to display the "High" bitrates and not the higher, "Extreme" bitrates.  Doing an "update library from tags" fixes this, and I can watch the reported bitrates suddenly pop to the correct, higher values.

I "think" that all this behavior (i.e. the incorrect reporting of both the "bitrate" and the "duration" information) is interconnected.

Thanks again for any feedback/help with this.  I've stopped ripping for the time being.

Larry

[lalittle]

UPDATE:  I just discovered an album that I ripped last March that shows the "incorrect duration" issue.  I don't know if it only recently started displaying incorrect info, or if I just never noticed it before.

It's also important to note that I don't "think" this was a re-rip.  I can't be certain anymore, but I'm pretty sure that I just ripped this album once.  This would of course mean that the issue is not limited to re-rips.

Larry

[scthom]

Usually this type of information comes from the decoder plugins.  I have not seen this with the flac plugin I've been testing over the weekend, so I expect there's something inside the MP3 plugin.

[lalittle]

Usually this type of information comes from the decoder plugins.  I have not seen this with the flac plugin I've been testing over the weekend, so I expect there's something inside the MP3 plugin.

To me, it seems more like an "interaction" issue between the encoder/decoder the ripping process.  I base this on the fact that when I view the same files on the same system with the same installation of MC but with a different library, everything appears fine.  If I had to guess (based on admittedly limited knowledge of this subject), I'd say that the problem resided in the ripping process, with MC not fully updating it's library after ripping.  It seems conspicuous that doing an "update library from tags" immediately after a rip appears to correct both the bitrate AND the duration information.

Thanks again,

Larry

[Alex B]

The thing that I don't get is why the problem occurs even after deleting the previous files.  You'd think that once you delete the songs, there would be nothing for MC to get "confused" by.

MC doesn't easily let the files go. It has a hidden deleted files database that contains all library field data of the deleted files.

Here's some info about it:
http://yabb.jriver.com/interact/index.php?topic=28266.0
http://yabb.jriver.com/interact/index.php?topic=29216.0
http://yabb.jriver.com/interact/index.php?topic=30238.0

To me, it seems more like an "interaction" issue between the encoder/decoder the ripping process.  I base this on the fact that when I view the same files on the same system with the same installation of MC but with a different library, everything appears fine.  If I had to guess (based on admittedly limited knowledge of this subject), I'd say that the problem resided in the ripping process, with MC not fully updating it's library after ripping.  It seems conspicuous that doing an "update library from tags" immediately after a rip appears to correct both the bitrate AND the duration information.

I have not tested reripping yet, but I think you are correct. It would be interesting to try if the same happens with Monkey's Audio, Ogg vorbis etc when the used compression setting is changed, but not the file type.

[lalittle]

MC doesn't easily let the files go. It has a hidden deleted files database that contains all library field data of the deleted files.

Here's some info about it:
http://yabb.jriver.com/interact/index.php?topic=28266.0
http://yabb.jriver.com/interact/index.php?topic=29216.0
http://yabb.jriver.com/interact/index.php?topic=30238.0

That's interesting, and definitely sounds like a potential area for this bug to be occurring.

I have not tested reripping yet, but I think you are correct. It would be interesting to try if the same happens with Monkey's Audio, Ogg vorbis etc when the used compression setting is changed, but not the file type.

I was going to test this, but after doing a LOT of testing over the weekend and figuring out the patterns reported above, I kind of used up more than my allotted time for this.  I was thinking (hoping) that perhaps I had already provided enough information to point to the source of the problem.  I'm willing to do more tests, but I'm waiting to see if the team actually needs any further testing before I spend more time on this.

Thanks for the information, and for any other feedback on this issue.

Larry

[GHammer]

I'll add a related item.
I recently had WMP be 'helpful' in tagging my files.
While fixing them, I am looking at all tags, adding better cover art and changing the naming of the cover art.
I see that many were tagged as "Best of the (fill in random decade here)" and of course the 'Band' was set as Various Artists.

I removed that tag externally from many MP3s. When I add the new cover art I am using 'Update library from tags'. I see the new cover art, but the 'Band' tag is still present in MC and still has the various artists value.

I have to close MC, move the file, start MC, wait for Otto to remove the selection, close MC, move the file back, open MC again, wait for Otto to import the file.

Then, and only then is the Band tag empty in MC.

I haven't seen this on any other formats, but that is likely because WMP only wrote to MP3s thankfully.

I'd consider this a bug in that, at least for MP3s, values are not being removed/updated from the library when they are removed from the files.

[Alex B]

GHammer, it think what you described is not related, but I try to answer quickly.

"Update Library (from tags)" updates changed data, but it does not remove valid library field values if the files do not happen to contain the corresponding tag fields. MC's library is designed so that it can work independently from the file tags if that is preferred.

[GHammer]

But... If the information 'changed', isn't there anymore, I'd like to see the change.
The tags of a file should not be ignored when specifically asked to update the library according to tags.

If MC is not remembering the info, where do you suppose it comes from?

[lalittle]

Is it an acceptable workaround for the time being to just run an "Update Library from Tags" after every rip (which is necessary in order to have the bitrate and duration fields report correctly)?  I'm concerned that there may be some deeper issues involved that may come into play down the road, so I'm reticent to continue re-ripping my collection while this issue remains.

Thanks,

Larry

[Alex B]

But... If the information 'changed', isn't there anymore, I'd like to see the change.
The tags of a file should not be ignored when specifically asked to update the library according to tags.

The commonly used tagging standards do not allow "empty" tags. Taggers remove also the tag headers when a tag field is emptied. MC would need to remove all library data that does not exist in the file tags.

If MC is not remembering the info, where do you suppose it comes from?

Sorry, I really don't understand this.

[Alex B]

Is it an acceptable workaround for the time being to just run an "Update Library from Tags" after every rip (which is necessary in order to have the bitrate and duration fields report correctly)?  I'm concerned that there may be some deeper issues involved that may come into play down the road, so I'm reticent to continue re-ripping my collection while this issue remains.

Thanks,

Larry

Personally, I would use a temporary library, rip to a temporary ripping location and replace the files outside MC. After that I would first do "Update tags (from library)" and then "Update Library (from tags)". The first command would apply my carefully tagged library data to the file tags and the second command would update the format info.

[lalittle]

Personally, I would use a temporary library, rip to a temporary ripping location and replace the files outside MC. After that I would first do "Update tags (from library)" and then "Update Library (from tags)". The first command would apply my carefully tagged library data to the file tags and the second command would update the format info.

Thanks.  Well... I was afraid it would be a bit more complex than I had been thinking.  Not that this method is "undoable," but I think I'd prefer to hold off on ripping for the time being until the issue is resolved (assuming, of course, that this is 'relatively' soon.)  I like to just start a rip, walk away, then come back and start another one.

On this note, does anyone from JR happen to know how high on the "to do" list this issue might be?  No pressure -- I'm just wondering if it's worth waiting or not to do more ripping (I'd rather not have to do the extra work if I don't have to.)

Thanks,

Larry

PS.  Alex -- so in order to get everything fully "updated," you have to update the library from the tags, and then update the tags from the library?  I didn't realize that this "back and forth" process was needed.

[GHammer]

The commonly used tagging standards do not allow "empty" tags. Taggers remove also the tag headers when a tag field is emptied. MC would need to remove all library data that does not exist in the file tags.

Yes, and if I have removed them and wish the library to reflect that, why wouldn't I think 'Update library from tags' should indeed make the library match?
I'm not sure it should be a one way street, add but never remove.

[lalittle]

Yes, and if I have removed them and wish the library to reflect that, why wouldn't I think 'Update library from tags' should indeed make the library match?
I'm not sure it should be a one way street, add but never remove.

I think it's actually necessary to take the "add but never remove" approach.  If the process removed tags that were empty, there would be no way to "combine" tags from both the library and the tags -- i.e. the process would eradicated one side of the equation even if "some" of the fields were correct on one side but missing on the other.  By using the "add but never remove" approach, tags that exist on the target but not on the source will be preserved, while the remaining tags will be added or updated.  This allows one to correct and add tags that are missing or incorrect without losing anything.

That said, this particular discussion might be better suited for another thread since it deals more with a design/work-flow philosophy rather than the original "ripping bug" issue.  This thread should probably remain focused on the "ripping bug," which is actually a "bug" that needs addressing.

Larry

[scthom]

Some of this logic resides in the plugins.

When MC does an update to tags, it will write out all tags -- some tags are blank and the plugins do recieve that.  Most plugins take that to mean that you should remove the tag (since it's blank).  It should be possible to make this a configuration setting.  See below for example.

The only command that removes tags regardless of content is Remove Tags.

Example:
Tag exists, value is something -- update the tag to the new value.
Tag exists, value is blank -- [Configurable] either 1) update the tag to the new value (blank), or 2) remove the tag.
Tag does not exist, value is something -- add the new tag.
Tag does not exist, value is blank -- do not add the tag.

Right now, all of my plugins are not configurable and take option 2.  I believe all other plugins do that as well.

[lalittle]

Let's try to keep this thread on the topic of the ripping bug, where duration and bitrate fields are misreported in MC.  For discussions regarding the tag updating logic, please start a new thread.

Jim -- would it be better to split the off-topic posts in this thread to the MC12 forum, and make the posts pertaining to the original issue (the ripping bug) active in the beta forum again?  The original issue still strikes me as the type of issue that goes in the beta forum?

Thanks,

Larry

[JohnT]

Thanks for reporting this Larry. It will be fixed in the next beta build.

[lalittle]

Thanks for reporting this Larry. It will be fixed in the next beta build.

Thanks.

Larry

[lalittle]

This issue is fixed in build 260.

Thanks,

Larry