Just for the record, Vocalpoint, there are LOTS of ways to solve the problems you listed here:
To be clear - I am not disagreeing with you or any of the suggestions and of course I aware that I could things differently or better. However not all of these "ways" actually solve problems - which I will address in a moment...
Of course, if your current system works for you, then there's no good reason to change it. But, I'd have to say that I agree with Jim, even with the reasons you stated. For the vast majority of users, it just wouldn't make sense to offer that option, and having it there would probably quite-often just cause confusion. For every person who actually wanted to use that option (all five of you), there would probably be 15 people who come in here complaining that their stuff is missing and that MC's ripping is completely broken (because they unchecked the option because they didn't understand what "the Library" is in the first place).
Well - I am very clear on what the "library" is on what I want it to do. I also believe there are numerous "options" that are in MC right now that do not benefit the "masses" and were included to meet a certain small pocket of users. And to this specific request - it would be "opt-out" in nature - in that a human would have to specific tell the system they do not want their ripped files appearing in the active library. Since the checkbox would never be on by default - there would be no way to introduce confusion. MC would handle ripped files as it always has until you specifically tell it not to. But if a user checks this box and then suddenly wonders why their files are not in the library - probably time to give their head a shake.
Just to explain one of the ways you could work around this without resorting to a separate ripping application:
1. Rip directly to a network location rather than a local drive on a machine that might get shut down (this would mitigate the issues with point 6-7).
2. Add a [IsTagged] flag to your Library, which you set from 0 to 1 when you've finished processing new rips. They will automatically be assigned 0 when they are ripped/imported.
3. Add a filter to each of your main "Top Level" views that hides any file where [IsTagged] == 0.
4. Then, you can have special Tagging/Importing/Prepping Views (perhaps under a new top-level Advanced View in the tree) where you can see and manage these files until you get them ready.
Or, as Jim pointed out, you could easily have a special "Media Ingest" Library that allows you to prep them separate from your main Library.
Also, you've probably explained it elsewhere, but you don't really explain the why of many of your points. I understand, but... It seems like it is simple "gospel" to you that the files shouldn't be in your Library (as though the "Library is sacred" somehow), without a reason why. That you don't want other users to see them before they're ready is a reason why, but that is easily mitigated.
Let me first speak to the "why" of it all first and specifically why my music management workflow HAD to change from some of the more "accepted" methods using MC as designed. First - "the moment". Back in August 2010 - I had my library out in Windows Home Server and was doing exactly what you outlined in some of your steps - like ripping to the server for example. I was using MC to rip to the server and everything was groovy. But I was also cavalier about backup and even more cavalier about any impacts of "loss" both in actual files and in lost metadata editing time. I was starting to really spend a ton of time tagging and ensure my music files were in tip top shape. But I never gave a crap about really ensuring the files were safe.
So one morning in August of 2010 - I played a specific playlist in MC and immediately noticed some glitching on a file...then another and a few moments later - another. I first thought network problems or a hard disk issue or anything that could be causing playback issues over the network. I believe I was on MC 16 at the time. After hours of diagnostics and finding nothing - I turned my attention to the source files. After downloading AudioChecker and a few other FLAC based tools - turns out that I had over 800 tracks in my server location that somehow went corrupt. The glitches were baked in. So I corralled together the list of "bad" files and it was then I realized that I had little to no backup for any these files (my total oversight). Long story short - it took me some months to recover from all this damage and it made me realize that my process (if you could even call it that) was sorely lacking in file management, backup and a bunch of other safeguards.
Hence the new workflow. Which was briefly outlined above - but here it is again:
1. Rip CD LOCALLY via whatever tool meets the task - currently dbPowerAmp
2. Ensure said tool puts ripped files in the specific Unreleased folder - where metadata edits will occurs
3. Use MC to fully tag the files
4. Use MC's Move, Replace Copy function to move the now "release" ready files to the Released folder
5. Create MC play copy - copy release files to the MC Library (Server) location using Win Explorer
6. Move the Release files to the Archive folder to be transferred to hard disk for long term storage.
The "why" of this workflow is simple.
1. Make maximum use of time and effort to focus on create the ultimate master "source"
2. Use master source to create the "play" copy - sent to the MC library location (SERVER)
3. Move master source special local staging area
4. Use SyncBack SE automation to move each master source file to two separate archival discs
5. One set of discs goes offsite
6. The other set is locked in a fire-proof safe onsite.
7. Ensure that I never ever have to worry about losing a "processed" file again
With regards to the "Library is sacred" - most definitely not. To me it's nothing more than fancy name for a file folder. It's a single spot where MC gets the honor to play what I choose to give it. And for my own ease of use - I want only a single location for it. I have no desire to manage multiple local paths or multiple libraries just to manage ripped files.
Now - to your list of possible solutions:
1. Rip directly to a network location rather than a local drive on a machine that might get shut down (this would mitigate the issues with point 6-7).
Solves little - as this "rip" is my actual master. Sending it to the network location will only mean having to move it back local for source prep and backup staging. Plus it would be not tagged properly at first rip.
2. Add a [IsTagged] flag to your Library, which you set from 0 to 1 when you've finished processing new rips. They will automatically be assigned 0 when they are ripped/imported.
Well - I could see this being useful - if I were to allow ripped, untagged, unreleased product to actually be in my "real" library location - and it's clear that I do not want this content ever getting to the server until it's deemed ready to be a true "play" copy. If I was starting from scratch with a small library - might be possible - but it sounds like a hassle at this stage with a large collection.
3. Add a filter to each of your main "Top Level" views that hides any file where [IsTagged] == 0.
See above.
4. Then, you can have special Tagging/Importing/Prepping Views (perhaps under a new top-level Advanced View in the tree) where you can see and manage these files until you get them ready.
Must admit that I have tried this - and I could not get it working with as much "flexibility" as I would like with Explorer. My main gripe here - (this is - after having to remove the Library reference if using MC to rip) is that there is no way to store Recent paths within the MC Rename, Move and Copy files utility. So if I tag up some files in MC and want to copy them to the Server - I have to hand type (or browse) to that path...and then when I want to move the final archive to my backup area - I have to hand type (or browse) to it again. Within my third party Explorer tool - I can do all of this very quickly with keyboard shortcuts and I can have the files where I need them in seconds.
To close - You know I love MC and have learned to overcome many of it's shortcomings - and understandably - my needs differ (possibly dramatically) from how others use it. Big difference here is that I need to control the creation, location and cleanup of the content and ultimately how MC gets to access it - not the other way around. So while the solutions offered here are excellent - they still require effort to create (custom views, filters, new fields etc), potential severe mods in workflow (like allowing local paths to infest the main library) all just to have MC to manage everything. All I need from MC is to keep the main library viable and be the erstwhile tagger and player here. It could be the ripper too...but until it learns it's place as a solid ripper instead trying to own the ripped files - probably won't happen.
Thanks for the updates.
Cheers,
VP
Author
Topic: best quality for ripping CDs (Read 10047 times)