dtc -p -b-8 -fdumpdir/<NameOfGame_> -i -i2 -y -g2 -i6 -l8 -t10
If you want to have a d64 simply change it to:
dtc -p -b-8 -f<dumpdir>/<NameOfGame_> -i -i2 -f<d64dir>/<nameofgame.d64> -y -g2 -i6 -l8 -t10
<NameOfGame_> is used for dumping so track files can't possibly get mixed up. The trailing _ just makes the file names tidy

NameOfGame is just whatever is written on the disk label as game title without spaces or special characters, without any copyright notices etc.
If it is a compilation and has disk numbers and titles I use the disk number:
e.g. CoinOpHitsII_Disk1_
If a compilation disk instead has a specific name:
e.g. MAX_NightShift_
If it is a standalone game just use the name as printed on the label:
e.g. DefenderOfTheCrown_Disc1_
If you use Total Commander, a quick check to do is the file number and sizes; you should have 168 files listed per disk, and you shouldn't encounter any 45 bytes long file; that's a transfer error.
Once a dump is complete just zip it up into a single archive for all disks belonging to the same title/compilation.
Things to watch out for - just in case, although you should have experienced some of it already...:
1. Don't run any other program in the background; it will result in the 45 bytes transfer error files eventually... We mean major applications here, not something that the OS would run anyway.
2. Some of our drives are known to show symptoms of static/overheating after a while - exact cause unknown, but if your drive has the same issue what you'd see is that known good disks will show errors despite the head being clean. Simply turn off the drive and wait a few minutes, it will "fix" it.
3. Many of the disks can be dirty, hard to read etc. IPA can be very handy for cleaning them - We use pure alcohol and destilled water or Servisol IPA 170 and it can help a lot.
4. Watch the output while dumping if it suddenly turns into something that looks suspicious chances are the head just got dirty. Do clean the drive head to prevent disk damage, then just start dumping a known good pre-formatted disk to verify the cleaning. Obviously clean the offending disk as well before using it again...
5. Always keep the command line as is, unless it's a multi-platform disk, e.g. Atari-8 bit plus CBM, in that case set the correct format for each side. Say side 0 is CBM and side 1 is A8 the format specification of the command line (after -i2) in the above example should look like this: -g0 -i6 -g1 -y -i3a -l8 -t10
6. If you keep on getting track number warnings, the head wondered off calibration. It can happen, if you break the execution below track 0.
Don't panic, just let the head move into the positive track domain, say until cbm track number 5 is being displayed, then reset the board using the small button on it. The next dump command will recalibrate correctly. It's easier to not break execution below 0 though

7. Once in a blue moon, you will encounter a disk that will display a track number warning, no matter what. The reason for that is the duplicator did not have a drive that could correctly go to -8, but the CBM drive will seek to the correct track anyway, as it reads the track position...
When/if ever that happens change the command line to use the correct offset, both heads will have an offset in these cases.e.g. -a+2 -b-6 for a drive that could only go to -6. We've seen two such disks so far out of hundreds.
8. Warnings are marked with a * e.g. OK* <some info text> *T is a track number warning. Watch out for those and act if needed, e.g. stop/restart dumping. The number displayed for track is the expected track number, the actual track number found is also displayed in brackets.
9. To correctly identify SKUs it is very important to have the info file filled in, we've attached an example, Rambo.txt.
Additionally, please make a scan or photo at a resolution that keeps every text readable of:
- front of the disk/label.
- back of the disk only if it has any markings
- front and back cover of the box, ensuring any copyright and publisher notices and years remain readable
- front and back cover of the inlays, ensuring any copyright and publisher notices and years remain readable
- code sheets if supplied
- manual if small, or manual pages with any copyright/year notices
10. Try and use the correct format for dumping a disk and replace the -i6 CBM image type accordingly. That can save a lot on redumping

You can get a list of image types by using DTC -h command.
The ones interesting for pure c64 disks are: 6 (CBM), 15 (CBM MicroProse), 16 (CBM RapidLok), 17 (CBM Datasoft), 18 (CBM Vorpal)
For CBM plus other format disks you might need: 4 (MFM, for PC sides), 3a (Atari 8-bit)
11. As always please use the latest beta version of DTC and firmware.
12. Please mark dumped disks as such with say a number on the disk with a stick it note, so they won't get mixed up with undumped ones - I know it's common sense, but in some cases we had to redump quite a few copies of the same title to find the correct disk to redump, as the labels were identical, but only one of them was needed - so labelling dumped disks can save a lot of time occassionally

13. Skipped, for scientific purposes... it would bring bad luck!
14. Do a few test dumps that can be checked, just in case.
15. DTC can detect modification for most formats, but it is not possible to verify games that were not professionally duplicated (very few) and RapidLok titles, EU versions of Melbourne House games. Both RL and MH titles use recording that cannot be checked for modification so we need multiple dumps of those, everything else can be verified for modification from a single dump. One company known for using home equipment for duplication is Datasoft.
Modified tracks are marked with a + sign in the output and the number after the plus sign is the number of modified sectors.
***NEW ***
When you dump a disk with a custom format, you may get tons of unformatted tracks, tons of errors or a mix of these two depending on the custom format used on the disk.
In these cases the disk should be dumped with the correct guide format, replacing the -i6 parameter.
For a list of all CBM custom formats supported enter dtc -h.
All formats between 15 and 21 are custom CBM formats used by various disks.
In the case of Gunship it is RapidLok, so the correct -i value is -i16
To have a good idea of which publisher used which format(s) please try and use the table below.
It is very important to have custom format disks dumped using the correct format, so errors can be detected and retried.
When we encounter something that is not supported at all (yet!) we do a blind dump of the disk, reverse-engineer the format, add it to DTC then do a redump.
Unfortunately, apart from having a hunch of which game uses which format the only way to know is trial and error.
Note, that there are lots of variants of these formats which DTC automatically detects during dumping and selects - however it must know where to look first to be able to decide on the finer details.
Generally speaking:
- most Epyx games use Vorpal, apart from the very early ones using simple CBM (i6), US Gold published Epyx games are again either Vorpal or CBM.
- Digital Integration might have used Vorpal, unconfirmed yet. (ATF - Advanced Tactical Fighter)
- MicroProse used MicroProse or RapidLok or CBM (MP: Stealth Fighter, Airborne Ranger, RL: Gunship, Pirates...)
- Accolade/Avantage: RapidLok
- Activision: CBM, RapidLok (in the US), V-MAX!
- Access: CBM or RapidLok
- Teque on any game developed by Teque, e.g. many original Grandslam titles (Terramex, Thunderbirds, Munsters... probably all others undumped as well)
- TDP is only known to be used on Dragon's Lair and Escape from Singe's Castle
- Datasoft on almost all Datasoft titles
- V-MAX! Cinemaware, and lots of other games originating from the US; Taito, Mindscape, Origin, Activision, Discovery Software so far