Print

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

[Hollingshead]

I'm getting really frustrated by JRiver replacing the first instance of a song if it finds another song with the same name while ripping. Isn't there someway to make it stop doing that? I rip a lot of "complete" sets and they often have multiple versions of the same song on a side and they aren't always designated as different takes. So JRiver just substitutes the last version of a song for ones that came before. For example, I just ripped the Ronnie Lane box and the last CD has two versions of Ohh-La-La, both live in Austin. So my ripped disc now includes two Track 9's and no Track 1. Why on earth does it do that?

In order to fix it, I have to close JRiver, because it will refuse to rip the disk again insisting that it is already ripped. Reopen it, uncheck all the tracks except Track 1 and rip that one track and then delete the second Track 9. And worse is when I don't notice it's happened until I no longer have the disk available and I'm stuck with two tracks and a missing track forever.

I appreciate how many things JRiver does very well, but this behavior seems so odd and so unnecessary. Is there a fix? If not, can we make that a feature request for the next release?

Thanks,
Kevin

[RoderickGI]

That can be fixed. The problem isn't with the ripping process, and track 1 isn't being overwritten. It is just at the metadata lookup phase that MC sets the wrong track number, and probably other details, on track 1. That is probably because of what is in the MC Album database that gets looked up, YADB.

That data comes from other users, so someone uploaded bad data at some time, and you are suffering the consequences. Make sure that when you insert a CD to rip and MC offers you a list of CDs that match, you pick one with the correct data. To see the list rather than have the first match selected, untick the setting "Options > CD, DVD & BD > CD Ripping > Auto Rip CD Database Lookup Options > If multiple matches are found, choose the first one".

The fix isn't to re-rip the track, but to just fix the metadata on track 1. To do that you need to identify which of the two copies of track 9 is actually track 1. You could do that by playing the tracks, or looking at the filename which will be different and may include the track number, or at worst case, looking at the time the two tracks were created. The file ripped earlier will be track 1.

Once you know which is track 1, edit the metadata to correct it, based on the CD in your hand, and all is fixed.


Once done, please submit your fixed Album details to YADB by right-clicking the Album thumbnail and selecting "Library Tools > Submit Track Info To Online Database".

Or better yet, at the start of the ripping process, when all the tracks are presented to you, use the "Edit Disc Information" button to fix any errors and then process the rip. At that stage you can clearly see the track numbers and the filename on the CD, such as "Track01.cda". If you have the setting "Options > General > Online Metadata > Allow automatic CD lookup / submission" ticked, which it sounds like you do, your corrections will be submitted to the online Album database, YADB. You should have everything ticked under that "Online Metadata" section if you want to improve the data.

[wer]

I don't use MC for ripping, I use dbPowerAmp, which is probably one of the most popular and capable rippers out there.  And dbPowerAmp has the same problem.

If the metadata from the online lookup is bad, and you have 3 versions of the same song on an album (say studio, live, and remix) that all have the same name in metadata, then what happens with dbPA is that you get 3 files, the 2nd and third with (1) and (2) after the name, since there is a name collision unless you are including track number as part of your filename rule.  That's annoying when the metadata is bad, but what can the program do?

I don't know if MC does the same thing or not, as I haven't been in that situation with it.  If it does the same thing, then now the OP knows he's no worse off than with other software.

If MC actually does only leave 1 file instead of 3 after the rip, that is bad behavior that should be fixed, by adopting the approach dbPA takes as described above.  As a work around you could include [Track #] as part of your file naming rule in MC, which would eliminate duplicate name collisions, but some people don't like that.

[Hollingshead]

I appreciate the considered responses from wer and RoderickGI, but that doesn't seem to be what happens. I have learned to be very careful with my metadata and, in fact, I have recently set my system to take no action when I insert a CD so I can check the metadata before it rips. And the metadata is correct.

On the example I cited, Track 1 is correctly identified as Ooh-la-la (Live in Austin) and it runs 3:52. Track 9 is also correctly identified as Ooh-la-la (Live in Austin) and it runs 3:39. But after I rip, I have two Track 9's, both listed at 3:39. And, if I click on one to play (as I just did hoping RoderickGI was correct and I could just relabel the first one), they both highlight and play. No matter which one I click on, they both are highlighted and they are the same.

As wer points out, I could use another program. In fact I used to use ExactAudioCopy and it doesn't have this problem. But it's simpler to just use JRiver and it works fine except for this issue. Actually, another good thing about EAC is their more robust metadata finding options, including album cover search. But still, I'd rather use JRiver.

[wer]

And the metadata is correct.

On the example I cited, Track 1 is correctly identified as Ooh-la-la (Live in Austin) and it runs 3:52. Track 9 is also correctly identified as Ooh-la-la (Live in Austin) and it runs 3:39.

In my view, the metadata is not correct, because you have given the exact same name to two different (diff running time) versions.  First, you need to please give us the rule you are using for JRiver to name the tracks during ripping.

But more importantly, what you have described above is giving the exact same name, album, and artist fields to two different tracks.  That can create a collision, unless your naming rule (which you have not yet provided) includes additional data.

When I encounter such a situation, I make sure that the name of the second track more accurately reflects what it is, by adding something like (Alt Version) or something else appropriate to the name.  That way the two tracks have different names, and no collision.

If your naming rule looks something like [Track #] - [Artist] - [Name] then you will not have collisions, because the track number won't be duplicated (unless you rip a multi disc set, then you need to include [Disc #] to be safe).  If your naming rule is just [Artist] - [Name] then you WILL have collisions if you give both tracks the exact same name.

Please show us your rule, but you might try the rip again using a variant of the rule I gave you above and see if that resolves your problem.

What you describe about having 2 files with the same duration sounds strange, but let's see if it's resolved by the rule change.

Also, check the filename in the MC database for both files and paste them here, so we can see if they are the same or different.  This is the contents of the [Filename] tag which you can show as a column in your view.  Also check the filesystem instead of the MC program, and look at the properties of the 2 files there to see if the duration is the same or different.

Finally, there is an option in the CD tab of the main options dialog in MC "Overwrite existing files that have the same name".  Make sure that is turned off.

[Hollingshead]

That was exactly what I was looking for! I had never seen that "Overwrite existing files" option before. Of course that's the answer.

Thanks very much.

[wer]

No problem.  Keep in mind the overwrite option would not need to save you if your metadata and naming rule accounted for the situation, as I described.

Good luck...