Topic: CD Ripping Changes for v10 (Read 8764 times)

JohnT · « **on:** December 09, 2003, 12:17:40 pm »

Here's a list of some changes in MC's ripping tool for version 10. These aren't "set in stone", so feel free to post your comments. Thanks!

1. Instead of the ripping dialog window, use MC's action window.

2. Allow ripping multiple tracks to one file and generating some sort of cue sheet.

3. Eliminate the analog ripping mode (and analog CD playback) and just have a check box for secure ripping mode.

4. Support a "read offset compensation", ala EAC in advanced CD ripping options. This would simply default to zero and a user could fill in an offset value.

5. Auto rip mode is always enabled. When rip is complete, user clicks "Done" or simply inserts another CD to rip.

6. Rearrange/clarify the settings dialogs.

7. More flexibility in letting the user choose where CD information is gathered from (YADB, CD-Text, cdplayer.ini, etc.).

hit_ny · « **Reply #1 on:** December 09, 2003, 12:48:39 pm »

would like to add

- burn audio cd given a cue file

Deivit · « **Reply #2 on:** December 09, 2003, 12:48:51 pm »

Quote from: JohnT on December 09, 2003, 12:17:40 pm

7. More flexibility in letting the user choose where CD information is gathered from (YADB, CD-Text, cdplayer.ini, etc.).

Currently, when the information is gathered from YADB and more than one match is found, the user is prompted to select one of the matches without having the ability to actually see what the details of each match are. This makes chosing from one of the matches a sort of a lottery. Sometimes you select the first one only to finally realize that it's the one that has all the artist fields filled with "various" and wondering whether the second one was the one that had the artist field correctly filled.

Would it be possible to have a preview in detail of what you are actually selecting?

Thanks for your time.

JimH · « **Reply #3 on:** December 09, 2003, 12:52:07 pm »

We expect to add something like this in the near future.

nila · « **Reply #4 on:** December 09, 2003, 12:52:15 pm »

Woot Woot - Go on John

Ok,

Here's some others to consider:

Hairstyle ripping mode so a CD can be ripped straight from hairstyle with a full hairstyle interface - also for Burning.
More ripping/compressing options:

- Rip and Encode Simultaneously
- Rip then encode each track
- Rip whole CD then encode in background even while ripping another CD (EAC Style)

Ability to rename tracks at any point not just in specific input boxes (eg when it shows the names of the tracks to be ripped we should be able to edit them on the spot).
YADB - When retrieving CD information - when multiple matches are found we should be able to see the track listing of each CD before deciding which to use.
I'd LOVE an offline lookup mode whereby we can rip TONS of CD's, MC saves the ID of each CD into each track and when we've finished ripping them all it can in one big batch, go online, lookup the CD information and get it for all the CD's, then apply the track info information to each mp3 afterwards.

Alot of houses in the UK cant/dont have broadband and so HTPC's dont have internet connection that is always on. Jim suggested putting each CD in first which would work but when doing ALOT of CD's, as I'm sure you can imagine it'd mean having to put 500 cd's in and out the drive twice each which would suck. This would really help to make it easier for those of us without always on connections - not sure how hard it'd be - you'll probably have to think about it abit :)

Thanks!! :)

Mirko · « **Reply #5 on:** December 09, 2003, 01:09:28 pm »

Thanks JRiver-guys, good things lay before us.

Quote from: Nila on December 09, 2003, 12:52:15 pm

- Rip and Encode Simultaneously
- Rip then encode each track
- Rip whole CD then encode in background even while ripping another CD (EAC Style)

Vote: YES, very important to me. Adds flexibility to the whole process (and gives me spare time to waste *g*). Idea: Add this to the action-window (more than one actionwindow for ripping (one per driver e.g.)).

Thanks for listening,
Mirko

zevele10 · « **Reply #6 on:** December 09, 2003, 04:32:03 pm »

JohnT

All the planed changes sound great.

To me 'More flexibility in letting the user choose where CD information is gathered from (YADB, CD-Text, cdplayer.ini, etc.). ' would be very nice.
Few things i would like :
-Tracks number before tracks names in the rip window

And some DSP effects-- well not sure if they are all DSP ,by the way- :

Add silence
Remove silence
Trim
Ad tag element
Remove tag element
Ad comment

And to put them in the convertion dialogue box as well.

If 'encode in the background' not a big job, just put it.
You will make many very happy and reduce the number of posts on Interact concerning it -- quite a lot as you know...-.

Do you have any ' road map' concerning Burn ?.

Again thank you for the great job on rip/burn

Ce.D · « **Reply #7 on:** December 09, 2003, 04:38:44 pm »

Quote from: JohnT on December 09, 2003, 12:17:40 pm

7. More flexibility in letting the user choose where CD information is gathered from (YADB, CD-Text, cdplayer.ini, etc.).

And include the Media Libary itself in the "etc." (re-rip). As mentioned , saving the CD ID somewhere for later use (like batch YADB-ing or re-ripping) would be great.

Thank you for looking into those matters and hearing us.

Sauzee · « **Reply #8 on:** December 09, 2003, 06:32:59 pm »

These suggestions all sound great to me, especially those related to ripping Cd's with cue files and more flexibility over where we get/store/reuse CD information.

If we get cue file support for ripping will we also have it for playback and will we get the info from the cue files in the MC library so that we can search for an individual track within a 'ripped as one file' CD ?

MachineHead · « **Reply #9 on:** December 09, 2003, 06:53:51 pm »

Additionally looking into freedb would be nice. It is massive.

Multiple encoder instances. READ: If my pc is stout enough to handle more than one instance of the dos window in the background, let me be able to choose so. Sometimes the rip is faster then the actual encoding itself. Two or more would be nice.

Cue sheets would be nice. As long as they are compliant type.

Haven't tried this in a while, dual drive capable ripping if desired. (?)

Sauzee · « **Reply #10 on:** December 09, 2003, 07:16:22 pm »

Quote from: Mirko on December 09, 2003, 01:09:28 pm

Thanks JRiver-guys, good things lay before us.

Quote from: Nila on December 09, 2003, 12:52:15 pm
- Rip and Encode Simultaneously
- Rip then encode each track
- Rip whole CD then encode in background even while ripping another CD (EAC Style)

Big vote winner for me as well
Vote: YES, very important to me. Adds flexibility to the whole process (and gives me spare time to waste *g*). Idea: Add this to the action-window (more than one actionwindow for ripping (one per driver e.g.)).

Thanks for listening,
Mirko

bvm · « **Reply #11 on:** December 10, 2003, 12:55:03 am »

Quote

5. Auto rip mode is always enabled. When rip is complete, user clicks "Done" or simply inserts another CD to rip.

Why? You already have a customizable setting that says whether to rip, play, or nothing when a CD is inserted. Are you proposing to take that away? Or do I misunderstand?

(I have it set to no action, since I pretty much always want to fiddle the tags before ripping.)

hit_ny · « **Reply #12 on:** December 10, 2003, 01:22:09 am »

Quote

If we get cue file support for ripping will we also have it for playback and will we get the info from the cue files in the MC library so that we can search for an individual track within a 'ripped as one file' CD ?

i have never got an offical answer on this at all. except they would take it into consideration. i am guessing we will, it would be odd indeed if one could rip tracks with cue and not be able to do much other than that, given MC's powerful database.

dwex · « **Reply #13 on:** December 10, 2003, 05:44:48 am »

Quote from: bvm on December 10, 2003, 12:55:03 am

Quote
5. Auto rip mode is always enabled. When rip is complete, user clicks "Done" or simply inserts another CD to rip.

Why? You already have a customizable setting that says whether to rip, play, or nothing when a CD is inserted. Are you proposing to take that away? Or do I misunderstand?

(I have it set to no action, since I pretty much always want to fiddle the tags before ripping.)

Agreed. Why remove the option?

--dwex

NoCodeUK · « **Reply #14 on:** December 10, 2003, 05:54:46 am »

I think you have misunderstood what is meant here by the auto rip. They are not talking about the auto insert dialog that comes up when a CD is inserted...I imagine that will stay the same. They are talking about the auto rip mode which is currently an option. basically it means once you start ripping if you wish to rip another cd rather than having to restart the process you can simply insert another cd and that will start ripping automatically too...

Hope this explains it all...

Adam

JohnT · « **Reply #15 on:** December 10, 2003, 09:15:05 am »

Thanks for clarifying the auto-rip change NoCodeUK, you got it right.

To answer another question, the MC database will support whatever cue file implementation we come up with so you can view/play the individual tracks within the multi-track music file.

Zevele, as far as CD burning, we're taking this one step at a time and I'm concentrating on the rip changes at the moment.

Thanks everyone for your comments/suggestions!

- John T.

zevele10 · « **Reply #16 on:** December 10, 2003, 09:44:14 am »

No problem captain !!!!!!

I just asked ,cause i think better to wait for the same kind of post from you concerning burning than to post now in a 546789 replies Topic.

Will start in few minutes a MASSIVE rip task

hit_ny · « **Reply #17 on:** December 10, 2003, 12:26:23 pm »

Quote

To answer another question, the MC database will support whatever cue file implementation we come up with so you can view/play the individual tracks within the multi-track music file.

Thanks for this....

Here's hoping it will be CUE/APL like in behavior rather than "just" winamp+mp3cue like

...meaning the tracks will be understood by MC as if they were separate tracks.

..rather than winamp+mp3cue which only displays the individual tracks in playing now fashion and no more.

nila · « **Reply #18 on:** December 10, 2003, 01:02:08 pm »

Quote from: hit_ny on December 10, 2003, 12:26:23 pm

Quote
To answer another question, the MC database will support whatever cue file implementation we come up with so you can view/play the individual tracks within the multi-track music file.

Thanks for this....

Here's hoping it will be CUE/APL like in behavior rather than "just" winamp+mp3cue like

...meaning the tracks will be understood by MC as if they were separate tracks.

..rather than winamp+mp3cue which only displays the individual tracks in playing now fashion and no more.

Dont you mean more: Helium2 like - that program knows how to handle cue's

Dave T · « **Reply #19 on:** December 10, 2003, 01:24:02 pm »

Please show more information about what's being ripped. I don't have it in front of me, but IIRC, the album name isn't shown, just the track names.

Also, I'd like to echo the request for doing the lookups in a batch, after ripping is done. I know of one person with a dialup internet connection who's holding off buying MC until this is implemented. He's got 100's of CD's to rip, and doesn't want to hog the phone line for the several days required to do that.

hit_ny · « **Reply #20 on:** December 10, 2003, 02:01:25 pm »

Quote

Dont you mean more: Helium2 like - that program knows how to handle cue's

i was referring to the ability to understand individual tracks, in a similar manner that APLs work for APE. So for instance if i had 2 albums A & B. i like tracks 2, 5, 7 from Album A and tracks 1, 3, 8 from Album B.

Assuming we use APLS, i can make a playlist with those tracks only and the player handles how to find them and displays any relevant track info associated with them like it does currently. This means u get to keep ur files intact for portable play and have the power to catalog/rate all the indivdual tracks as well.

Foobar2K can do this already with any audio format (not just APE) using APLs...so i know its possible in theory. I'm not advocating they use APLS per se, so long as the behavior i described is possible.

As opposed to winamp+mp3cue style, which just recognises the cue file and allows you to play things and nothing more. I believe MC can be a heck of a lot better than that.

im not familiar with Helium2 cue capability is it like what i describved above ?

xen-uno · « **Reply #21 on:** December 10, 2003, 05:02:14 pm »

Along with everything mentioned so far (it's all good...baby), I'd like to see another file time stamp option for data CD's. Let me explain...

If you create a data CD (say...from a playlist) and lose the playlist, there is virtually no way you can know in what order the files were written. This is because no program I know off can sort via the hexidecimal or physical address of the files on CD. I propose that the first file written has the current time (ie 12:00:00 PM). All subsequent files would be incremented by one minute each (2nd file = 12:01:00 PM, 3rd = 12:02:00 PM, etc.). This would make the sorting of CD contents a snap. Currently, I believe there is two flavors...a mastering date/time (a non incremented value applied to all files) and the original encoded date/time (as shown on your hard drive). Let's bring on a third.

10^-27

edit: I guess this would be a Burning enhancement

JohnT · « **Reply #22 on:** December 11, 2003, 10:18:42 am »

Quote from: xen-uno on December 10, 2003, 05:02:14 pm

Along with everything mentioned so far (it's all good...baby), I'd like to see another file time stamp option for data CD's. Let me explain...

If you create a data CD (say...from a playlist) and lose the playlist, there is virtually no way you can know in what order the files were written. This is because no program I know off can sort via the hexidecimal or physical address of the files on CD. I propose that the first file written has the current time (ie 12:00:00 PM). All subsequent files would be incremented by one minute each (2nd file = 12:01:00 PM, 3rd = 12:02:00 PM, etc.). This would make the sorting of CD contents a snap. Currently, I believe there is two flavors...a mastering date/time (a non incremented value applied to all files) and the original encoded date/time (as shown on your hard drive). Let's bring on a third.

10^-27

edit: I guess this would be a Burning enhancement

Darn! That's the way it worked when I first implemented it. Each file date/time was incremented by one second in the order of the playlist. Nobody seemed to find much utility in that and preferred the last modification time. Maybe a future option...

kiwi · « **Reply #23 on:** December 11, 2003, 01:42:47 pm »

I'd like to be able to feed CDs in and rip and then be able to do YADB searches and tagging after. (In some nice manner.)

kiwi

skeeterfood · « **Reply #24 on:** December 11, 2003, 02:05:02 pm »

Please Please Please change it so that the 'Options->Close' menu item at least asks if you really want to make a coaster before it closes and empty CDR.

Oh, and how in the world do I burn a non-multi-session data CD with MC? My RioVolt SP65 doesn't seem to be able to read Multi-Session CDs...

-John

Cmagic · « **Reply #25 on:** December 11, 2003, 03:00:06 pm »

Great news John ! thanks.

Now let me think, what I'd like to add ?....

Ah yes ! could you please keep the analog ripping method and add an option so that we can rip vinyls LPs straight from the CD drive ?

thanks, you're great.

C.

zevele10 · « **Reply #26 on:** December 11, 2003, 07:07:59 pm »

Cmagic gets the point..

We need Analog
Still have to try with LPs
But with cassettes and 7" ,it works like a charme.

Now , if you want to make some pocket money , you can built a cd drive with enought room to read Super8 and Real to Real.

Sure ,it is a small market , but of very good buyers...

kiwi · « **Reply #27 on:** December 12, 2003, 03:10:21 pm »

zevele ~ I don't think that they are removing "analog" recording from MC. You can still record from your mic and line-in. My understanding is that they have removed the option of recording from the CD player's line out. i.e. that extra little cable that comes with a CD Drive that I haven't used in 3+ years.

Analog recording is great for analog sources, however, for digital sources, digital extraction is the way to go.

kiwi

zevele10 · « **Reply #28 on:** December 12, 2003, 03:22:43 pm »

You are rigth, i know it.

I was just adding to the CMagic joke.
If you remove Analog from Recorder, better to remove it.
I never used analog rip.

What is the situation when you need to use it?

xen-uno · « **Reply #29 on:** December 12, 2003, 04:56:38 pm »

It is a more error tolerant ripping mode for less than perfect disks. Uses the drive's error correction (Solomon-Reed) instead of computer based (software) correction.

10^-27

zevele10 · « **Reply #30 on:** December 14, 2003, 08:05:20 am »

After around 300 cds ripped since my last post, 3 small [?] improvements

A-to be able to set "save log' as default in SecureRip

B-to get a message if the cd allready ripped with the same settings [ encoding settings i mean]

C- to have the full infos in the rip window==Artist ,Album names TRACK NUMBER andTrack name. And ,of cause to be able to edit them.

After what can be see as intense usage ,not the smaller problem on MC-rip side.
Cannot say the same about YADB.. but it is not your domain

Have a good week-end

MachineHead · « **Reply #31 on:** January 13, 2004, 07:48:27 pm »

Any idea when these changes may occur? It was the main reason for me to upgrade and as of yet do not if anything from this thead has made it into current MC beta.

Was this just a worm and I took the bait? Only to get stuck with a hook...

JohnT · « **Reply #32 on:** January 14, 2004, 07:02:33 am »

Most of the changes are complete in MC's internal ripping engine. "Only" need to hook everything to the GUI and make it work with MC's database.

Quisp · « **Reply #33 on:** January 14, 2004, 09:22:42 am »

Quote from: JohnT on December 09, 2003, 12:17:40 pm

2. Allow ripping multiple tracks to one file and generating some sort of cue sheet.

I hope this will support playing mulitple tracks based on an external cue sheet also and will work with burning as I think was mentioned before. Thanks!

Look forward to the integration!

tjobbins · « **Reply #34 on:** January 14, 2004, 11:22:27 am »

I would still really really love to be able to rip more than one CD at once, where the user has multiple CD drives

I would imagine this to work visually by either displaying multiple rip queues, one per drive, or by having a single queue but with a column that indicates which drive each track is on.

Would save a lot of time for those of us with multiple drives, and a lot of disks to rip

Thanks for all the hard work

Tom

sertua · « **Reply #35 on:** January 14, 2004, 12:52:26 pm »

I'd like to echo the following:

Rip and encode simultaneously, with possibility to pause/resume the encoding process somewhat like EAC
Rip whole CD or a few tracks and then encode in background when chosen
Multiple encoder instances
Batch lookups in YADB

Thank you for improving the ripping engine!

phelt · « **Reply #36 on:** January 14, 2004, 01:53:34 pm »

Quote from: JohnT on December 09, 2003, 12:17:40 pm

4. Support a "read offset compensation", ala EAC in advanced CD ripping options. This would simply default to zero and a user could fill in an offset value.

Or you could check out AccurateRip.

shawnholt · « **Reply #37 on:** January 14, 2004, 01:58:50 pm »

what happed to the rip "rate"? Also, When I use 2 CD rippers, and add to second one, doesn't always recognize the insert.

finally - eject after rip does not work.

S.

INTERACT FORUM

Author Topic: CD Ripping Changes for v10 (Read 8764 times)

nila

zevele10

MachineHead

zevele10

nila

zevele10

zevele10

zevele10

MachineHead

phelt