Topic: Rip workflow (Read 5814 times)

lalittle · « **on:** April 06, 2004, 03:03:49 am »

After a rip finishes, MC10 instructs you to enter another CD if you want to continue ripping. Rather than waiting to allow you to check the tag information (which quite often has spelling or other errors in it, such as the artist AND the title in the "name" field) it simply launches right into a new rip. This means that you have to "cancel" the rip just to CHECK the tags, then restart the rip. On top of this, if you're using the "secure" option, you have to close the "rip report" window before you can even cancel the rip.

Why were these changes made to MC's previously elegant CD ripping workflow? Do some people object to having to hit "rip" just ONCE to start each rip? I don't see any advantage in eliminating a single buttom click when this adds such an important step in rip workflow.

I think the following workflow (which I believe is the exactly how MC used to work if memory serves) would be preferred by most people:

1) At the end of a rip, the "secure rip" report IMMEDIATELY comes up. There is simply no reason to have it wait for another action before it's displayed. This is information that you'll want to see immediately after the rip, so it should simply be brought up right away.

2) If you insert another CD, it does NOT start ripping right off the bat, but rather it waits for you to hit the "rip" button again -- i.e. it works exactly like what happens when you go to the "rip" window with a new CD in the drive.

3) MC waits for you to hit the "rip" button before actually starting each rip. If you want to check the tags and edit them at all, this is when you can do it. Once the tags are checked (or if you do not need to check them) you simply hit "rip" again and the rip begins.

This seems like a much more elegant rip process -- and it's not even my idea... it's the way MC used to work. You gain the ability to check the tags, and the rip report comes up without requiring an extra action. The way it currently works strikes me as a bit clumsy -- you have to close and open the rip window EVERY time if you prefer to check the tags before a rip, which I believe the VAST majority of people prefer to do.

Larry

Sir Alan · « **Reply #1 on:** April 06, 2004, 04:03:20 am »

I second Larry's remarks.

I find that almost every CD database entry has to be edited - either because it contains typos, or the format is not compatible with my preferred layout.

It would also be helpful if there was a facility for correcting typos - I have submitted several new entries myself, only to notice (just after hitting the Submit button) that I too had had finger trouble.

enigman · « **Reply #2 on:** April 06, 2004, 08:53:39 am »

I concur. I've tried to update my workflow by using 2 drives - ripping on one drive while checking and editing tags on the next CD with the 2nd drive, but if MC is already in "rip" mode for drive 1 when I pop a disc in the second drive, the tracks automatically get added to the rip cue - and there doesn't seem to be any way to edit or remove tracks from the rip cue once they're already in there and in "pending" mode.

Once a track is cued to rip, if I eject the CD from drive 2 and put another one in while MC is still ripping on the 1st drive (for example, if the CD isn't recognized, I may want to put it aside to handle all of my CDs that require track entry in one go) the track names from the previous CD (CD 2) remain in the rip cue and are not updated with information from the new CD (CD 3).

What ends up happening is that once the 1st CD is finished ripping, MC automatically starts ripping tracks off the 3rd CD with the names from the 2nd CD (in my case, generally Track 1, Track 2, etc). To me, I'd say this is a bug, not a feature.

JohnT · « **Reply #3 on:** April 06, 2004, 01:17:43 pm »

Quote from: lalittle on April 06, 2004, 03:03:49 am

A while ago, MC changed to what strikes me as an irritating workflow for ripping multiple CDs. After a rip finishes, it instructs you to enter another CD if you want to continue ripping. Rather than waiting to allow you to check the tag information (which quite often has spelling or other errors in it, such as the artist AND the title in the "name" field) it simply launches right into a new rip.

Are you ripping one CD at a time? If so, you should be able to make the tag changes upon completion of the rip. When you've made all your changes, insert the next CD to rip.
Is there a problem making the changes after the rip rather than before?

Matt · « **Reply #4 on:** April 06, 2004, 01:28:30 pm »

Quote from: JohnT on April 06, 2004, 01:17:43 pm

Is there a problem making the changes after the rip rather than before?

Then you need to fix the tags and the filename.

If you do it before, the filenames will automatically be right.

lalittle · « **Reply #5 on:** April 06, 2004, 03:44:11 pm »

Quote

Is there a problem making the changes after the rip rather than before?

Making tag changes AFTER the rip will only update the mp3s, but it won't update your CD database and therefore won't allow you to submit the corrections to the online database. This means that you'd have to make 2 sets of corrections in order to fix ALL the tags -- once for the mp3s and once for the CD itself. Fixing the tags BEFORE the rip does all the fixes at once -- it fixes the information for your CD database, allows you to submit these changes to the databalse, and then uses these changes for the mp3s as well.

It's also non-intuitive to put all the files on your system with potentially incorrect tags and THEN fix them. It's more logical workflow to fix everything right when the CD is first inserted.

The bottom line is the fact that the ONLY downside (if you want to call it that) to doing it the way I'm suggesting (which is the way it used to work) is that it requires a SINGLE extra button hit to start the rip. There are definite downsides, however, to the way it currently works.

Larry

JimH · « **Reply #6 on:** April 06, 2004, 05:09:53 pm »

Listening to: 'Write Your Own Song' from 'Asleep At The Wheel' by 'Asleep At The Wheel' on Media Center 10

Sir Alan · « **Reply #7 on:** April 06, 2004, 06:49:42 pm »

Quote from: JimH on April 06, 2004, 05:09:53 pm

Listening to: 'Write Your Own Song' from 'Asleep At The Wheel' by 'Asleep At The Wheel' on Media Center 10

No slacking, there! O'Grady says "Get on with it!"

lalittle · « **Reply #8 on:** April 07, 2004, 12:12:54 am »

I apologize if I offended anyone with the word "irritating" in the original title of this thread. I actually went looking for the post in order to edit the title to something less harsh and couldn't find it since it had already been changed. I didn't mean this to be insulting. I was simply trying to express what came to mind as I was ripping last night -- it really was "irritating" that this was happening -- but I should have used different language.

Once again, my suggestion is not my own idea -- it's based on the way MC used to work before it was changed. I found the previous MC ripping workflow (described above) to be elegant and intuitive, but the new workflow is not.

Larry

lalittle · « **Reply #9 on:** April 07, 2004, 05:01:30 pm »

Perhaps is someone could explain WHY it was changed from the way it originally worked I would understand this. At the moment, it just seems like they took a really elegant part of the program and made it a bit "clumsy."

What is the downside of the single extra step of having to hit the "rip" button to actually start each new rip?

It looks like Matt agrees with this idea in his post above -- he noted that if you just launch the new rip automatically, you have to edit TWO sets of tags instead of one in order to make corrections. Does his comment imply that this will be changed back to the previous workflow?

Larry

JimH · « **Reply #10 on:** April 07, 2004, 05:49:11 pm »

Larry,
A. We can't take the time to explain every aspect of what we do. It's impossible.

B. Everyone has different ideas about how things can be done.

C. We're about to ship, so no changes like this could happen, even if we thought it was the right thing.

Please bring it up again when we begin development of the next version.

Jim

lalittle · « **Reply #11 on:** April 07, 2004, 06:19:06 pm »

Quote from: JimH on April 07, 2004, 05:49:11 pm

Larry,
A. We can't take the time to explain every aspect of what we do. It's impossible.

B. Everyone has different ideas about how things can be done.

C. We're about to ship, so no changes like this could happen, even if we thought it was the right thing.

Please bring it up again when we begin development of the next version.

Jim

But consider the possiblity that NONE of your customers actually prefers it the way it currently works -- which is a very likely possibility given that so far, nobody can offer any reasons for the current workflow. It's true that everybody has different ideas about the way things should work, but does ANYBODY really want to take away the ability to verify the tags before ripping? Where is the logic in this? Does even ONE person actually think this is a "better" workflow just because it eliminates a single button press?

I understand that making changes can be difficult, but in all fairness this might be a "relatively" small change -- it's certainly smaller than some of the other changes you're making these days. To be fair, you guys just recently came out with a "3D pong" visualization -- isn't that far more complex than adding a button press for ripping? To say we have to wait for an entire new version of the product is basically saying "too bad -- live with it." Is it possible that this could be changed in THIS version, but perhaps just not until after it's out? To have to wait for the next whole verison to fix something that effects everyday workflow is kind of depressing.

Thanks again,

Larry

JimH · « **Reply #12 on:** April 07, 2004, 06:21:11 pm »

Quote from: lalittle on April 07, 2004, 06:19:06 pm

But consider the possiblity that NONE of your customers actually prefers it the way it currently works --

Not a safe assumption, Larry. We often make a change that people seem to want and then find out that there were people who liked it fine and are upset that we changed it. I'm not lying.

lalittle · « **Reply #13 on:** April 07, 2004, 06:44:02 pm »

I believe you, but in this case I'd bet that the VAST majority of people (if not ALL of them) prefer to take a gander at the tags just to make sure they're correct before ripping. I find blatant errors over half the time, and small ones at least 80% or 90% of the time. Some discs even come up with the entirely wrong CD. Where is the logic in taking away this ability? I seriously doubt anybody would argue against having the ABILITY to check the tags even if they didn't want to take advantage of it -- a single extra button press is just not an issue for most people.

I really think this is an issue that was decided by someone who doesn't rip very much. Anybody who rips a lot of CDs knows that the tags are incorrect WAY to often to just trust them without checking.

Larry

Nolonemo · « **Reply #14 on:** April 07, 2004, 06:59:00 pm »

I gotta agree with Larry on this, I prefer to get things as neat as possible before ripping, especially if it affects my file naming (I have both folder-based and tag-based handhelds and I have to keep both happy).

bvm · « **Reply #15 on:** April 07, 2004, 11:47:06 pm »

Quote from: lalittle on April 07, 2004, 06:44:02 pm

I really think this is an issue that was decided by someone who doesn't rip very much.

Sure seems that way to me, too. It's the rare CD that I don't fiddle with the tags before ripping. Of course, the situation isn't dire -- I just have to remember to do 3 clicks in between rips (close the Rip window before inserting the next CD; then after inserting CD click on Rip CD, and then Rip), instead of the ideal 1 click that Larry proposes above.

GHammer · « **Reply #16 on:** April 08, 2004, 12:54:51 am »

Personally I always like to see the info before starting any operation.

JohnT · « **Reply #17 on:** April 08, 2004, 08:41:22 am »

Quote

To have to wait for the next whole version to fix something that effects everyday workflow is kind of depressing.

Don't worry, it probably won't be that long.
As to the reasoning behind the change, actually there are a LOT of people (80%, 90%?) that just want to slip in their new CD, click a button to rip, and then listen to it. Count my wife in that camp, for her the word "workflow" as applied to getting her new CD into the computer does not compute.
That aside, I agree that it's important to make the process of ripping large collections as efficient as possible so we'll probably make allowances soon, just not right now.

Thanks for the feedback and patience.
John T.

lalittle · « **Reply #18 on:** April 08, 2004, 03:38:02 pm »

Quote

Don't worry, it probably won't be that long.
As to the reasoning behind the change, actually there are a LOT of people (80%, 90%?) that just want to slip in their new CD, click a button to rip,

Thanks John -- that's good news. As far as wanting to just "rip and listen," what I'm suggesting doesn't make it any harder to to this -- the difference is just a SINGLE click of the "rip" button to start EACH rip rather than having it auto-start when each new CD is entered. If you're only ripping a single CD, there is literally NO difference. The point is to have the OPTION of checking the tags, which is not possible with the current version without closing and re-openning the rip window in between each rip.

Thanks,

Larry

cryst · « **Reply #19 on:** April 08, 2004, 05:34:29 pm »

I agree with lalittle here. I was put off by the recent changes to the ripping process.

lalittle · « **Reply #20 on:** April 24, 2004, 05:49:45 am »

Now that MC 10 is out, is there any chance of re-visiting this topic? I think the rip workflow could be greatly improved for many people with negligible impact on the people that don't mind the way it currently works. Please see the suggestions in the first post of this thread.

Thanks,

Larry

pipsqueak · « **Reply #21 on:** April 24, 2004, 05:34:40 pm »

add me to the change it pile

GRAYDOG · « **Reply #22 on:** April 24, 2004, 09:50:57 pm »

I alway's like to see what I'm doin first so count Me in with lalittle

paulr · « **Reply #23 on:** April 25, 2004, 02:43:25 am »

I reported a bug that relates to this in the last two versions..

When the ripping log pops up, if you insert a CD into the drive while the log window is still active, it will start ripping with NO chance for any user input or review of the file tags... It just starts ripping.

Then, when you click Save to save the ripping log, then click ON, the ripping process STOPS and partial files are left on your hard disk and not in your library.

I do not think that it should start ripping a new CD by itself with no user input... What if I inserted a CD I already ripped? It would either start overwriting my files, or name the new ones with a (#). Not to mention the fact that the tags cannot be checked and corrected PRIOR to ripping.

RandyP · « **Reply #24 on:** June 15, 2004, 06:17:33 am »

Quote

I always like to see what I'm doin first so count me in with lalittle

I recently upgraded to v10, and ran into this a couple days ago. So often the downloaded album information contains errors, I can't imagine why we've lost the ability to edit the tags prior to ripping. I see no posts in this thread from customers who believe v10's method is better, yet the first issues of v11 are coming and this remains unchanged.

Quote

B. Everyone has different ideas about how things can be done.

Would a recording option "Allow tag editing before ripping" be sacrilege? It seems so simple to allow both user preferences.

Quote

...it's important to make the process of ripping large collections as efficient as possible

If the on-line data was correct 90% of the time, the v10 method would be a tiny percentage of time faster. Since it is not, the process is now more cumbersome. If efficiency is the goal, v9 is the solution.

jleerigby · « **Reply #25 on:** June 15, 2004, 07:54:42 am »

I agree 100% with Larry on this. I've recently started ripping a load of new CD's and I would say that the word 'irritating' is a well chosen one for this feature. I think Matt's point is a good one too. If I can remember I cancel the rip in between CD's but if I forget I then have to remember to go and correct the tags and rename all the files.

kaiynne · « **Reply #26 on:** June 15, 2004, 07:48:02 pm »

There is one aspect of the new ripping scheme that I like, which is that you can have a log with multiple cds in it, because the log just adds the new cd to the rip log. Before when you were ripping i remeber having to save each log individually which was a problem because i am trying to save all of my loggs into a single spreadsheet, and the fewer logs there are the less effort for me.

Other than that there doesn't really seem to be any redeeming qualities to the new rip proccess, and an automatic saving of the rip log into the indivdual album folder would completely remove any need to collate one big log file.

EpF · « **Reply #27 on:** June 15, 2004, 09:00:57 pm »

I'm in the 'make it like Larry says' camp too! With the option to auto-save the log with the ripped files...

Listening to: Del Shannon - 'Hats Off To Larry', from '60's U.S. Gold'

paulr · « **Reply #28 on:** June 15, 2004, 11:54:32 pm »

I'd like to see this change as well. If it starts to rip the next CD (without input from the user) and you cancel it, the partial file is left in the library... Very annoying.

An option to autosave the rip log would be much appreciated as well (I prefer to save the securerip.log file, one per CD, in each CDs directory).

lalittle · « **Reply #29 on:** June 24, 2004, 07:44:18 pm »

Is this something that's being looked into for MC10? I'm just curious whether or not I should hold out hope for this in the near future.

Thanks,

Larry

JimH · « **Reply #30 on:** June 24, 2004, 07:54:50 pm »

MC10 won't change now, except for bug fixes, and only if they are big and bad.

lalittle · « **Reply #31 on:** June 24, 2004, 09:31:52 pm »

Quote from: JimH on June 24, 2004, 07:54:50 pm

MC10 won't change now, except for bug fixes, and only if they are big and bad.

That's disappointing, especially given that you guys had a terrific rip workflow design with version 9.1, but decided to change it for some reason.

I'm being honest when I say I get annoyed every time I do any ripping with MC. If I forget to hit "close" after every CD, it starts to rip before I've had a chance to verify tags. I can't stop the rip because the secure rip report comes up, which I have to quickly close in order to stop the rip. At this point, I lose the secure rip report. I could of couse "save" the rip report, then close the report dialogue, shut down the rip, navigate to the rip report and open it with notepad, then delete the report... but what a pain all this is. It would be SO much nicer if MC brought up the report directly after the rip, then waited for me to press "rip" before ripping the next CD, giving me a chance to confirm the tags.

All the rip features in MC are great, and certain aspects of the workflow are better than before, but a few aspects of the rip workflow are totally illogical (as outlined above.)

Larry

GHammer · « **Reply #32 on:** June 24, 2004, 11:52:02 pm »

Quote from: JimH on June 24, 2004, 07:54:50 pm

MC10 won't change now, except for bug fixes, and only if they are big and bad.

So then MC 10 users have been, as I like to say, kicked to the curb in favor of MC 11 development.

How nice.

JimH · « **Reply #33 on:** June 25, 2004, 07:13:46 am »

Every version has a beginning, a middle, and an end. 10.0 has ended. The future is still a mystery.

lalittle · « **Reply #34 on:** June 25, 2004, 07:40:12 am »

Quote from: JimH on June 25, 2004, 07:13:46 am

Every version has a beginning, a middle, and an end. 10.0 has ended.

Only 3 months after it's release? I understand the need to sell new products, but what happened to interim releases -- i.e. 10.1 (9.1 saw numerous improvements and changes before 10 took over.) It's not like we're asking for huge changes (i.e. allowing tags to be edited before automatically starting to rip, or bringing up the secure rip report before the new CD starts ripping.) These are interim level changes, and 11 won't be out for quite a while.

Is it really a done deal that these type of changes are simply not going to happen before 11?

Thanks,

Larry

Jakester · « **Reply #35 on:** June 29, 2004, 10:35:42 pm »

I'm definitely with Larry on this. I am about to rip 800+ CDs. The workflow as is will be unpleasant at best. From a software point of view, this appears a simple change. Should be a simple dialog change with a few lines of code change in some logic flow somewhere. Yes I'm new to this package but a little reading on this bulletin board shows the real users and backers of this software seem to agree on this point.

lalittle · « **Reply #36 on:** June 29, 2004, 10:54:36 pm »

Thanks for all the responses here.

JRiver has been responsive to MC users on other issues -- hopefully this will be something that they'll still look into.

Larry

paulr · « **Reply #37 on:** June 29, 2004, 11:12:11 pm »

Agreed. It's very annoying as it stands.

Omni · « **Reply #38 on:** August 03, 2004, 10:20:14 pm »

Not to bump an old thread, but I just ran into this, er, annoyance this evening.

I recall being in Matt's camp at the time and just thinking that one can just as easily update the tags after the rip as they can before the rip, but you know what they say: Experience is the best teacher.

With that said, the fundamental flaw I found in Matt's approach this evening is that he is assuming that every CD ripped in one session exists in the YaBB database. Oh, that's so not true.

(Roughly 25% of my collection is not [or at least was not at the time of the original rip] in YaBB, and I am a very mainsteam type of guy, too! No weirdo Indie stuff here.

)

When all is said and done, you are potentially left with numerous "Unknown Album," "Unknown Name," etc. duplicates to sift through. How is this handled?

Okay, I don't seriously expect an official response to this post given the age of thread, but please, please, please fix this in MC 11 at least. Thank you.

(BTW, I guess this isn't the fundamental flaw in that paulr raised an excellent point as well about potentially reripping tracks and losing any and all previous updates.)

INTERACT FORUM

Author Topic: Rip workflow (Read 5814 times)

cryst

jleerigby