Annotated ····· Single HTML file ····· Plain text file

Newbie Advice Guidelines

0. Preface

The Nags have been adapted from several boilerplate messages used over the last several years to help aba/abma binary posters be aware of various behaviors that may not necessarily be in the best interest of the groups as a whole. As such, the nags are aimed primarily toward newbies -- note the acronym and are directed toward very specific and constantly reoccurring posting problems. All general questions should be referred to the FAQ or either the Web based or Usenet based discussion groups.

All Nags are not created equal. Some, like No floods or No hentai, relate to maintaining the very viability of the groups; others, like Test in a.b.test or Ep # before part count, are just to reduce the general annoyance factor for everyone. But most are concerned with that vast middle-ground of just keeping the groups running efficiently and reducing the strain on our always-limited bandwidth.

Maintained by (inc) - 2003-05-12 version

1. Please do not post hentai in aba/abma/abmar

1. It is explicitly against the aba and abma charters.

2. Do not give isp's a reason to drop aba/abma. If I may quote from Marco van Loon (the originator of abma):: "It doesn't contain *erotic(a)* in the name, so allowing hentai material would make this a stealth erotica newsgroup." and thus a target for isp's wishing to "clean up" Usenet.

3. Other groups already exist that are more appropriate for hentai posts. Recently alt.binaries.multimedia.erotica.anime has been the "default" hentai ng.

2. When posting with PP2K, always put the "$F" at the end of the subject line

When posting with PowerPost2000 (PP2K as it is generally known), it is always best to put the $F parameter last on the subject line, else the parsers in many news-readers can get confused-- they may not be able to discern the segment count from the part count (if it is included), and, thus can't determine the attachment name for auto-joining. Hence a fair number of people may see your post as hundreds of unjoined messages, requiring error prone manual-joins. This will cause many to just ignore your post out-of-hand, thus wasting BW. And some just plonk (filter you out) from the annoyance factor, which will never be of any help to you.

3. When posting binaries with Agent, make sure each file attachment is in its own message

When posting binaries with Agent each part must be in its own message otherwise auto-join fails, necessitating an error-prone manual-join. The choices are either loading the Agent queue with the add-on AgentPost:

Or better, using PP2K:

A good version for yEnc posting is at:

4. Don't post unRARed binaries

Please do not post un-rared posts into aba/abma. This isn't a good thing for multiple reasons: If the post has missing segments, it is just a huge waste of bandwidth as fills can not be posted and, to get a complete post, the whole thing must be redone. In the (rare) case where you may know how and do repost individual message segments with, say, some version of PowerPost 2000, other people still can't do fills, nor are you likely to be able to so successfully for more then a day or two. With rared parts, someone else can do fills easily at a much later date.

Also, you would be forgoing the CRC checking inherent in RAR (though using yEnc transport or posting an SFV may mitigate this -- see the faq), and may be propagating bit-damaged episodes -- a news-reader will not necessarily protest joining segments that have been damaged in transit.

5. Turn on *Recover* when RARing posts

Turning on Recover when creating a RAR'd set would seem to be an obvious move, as it can save yourself and others a lot of grief, negating some of the need to do fills and even full reposts.

PARs and RAR Repair should both be used on all posts: one is not really a replacement for the other. The benefits (for a default 1% size increase in your part sizes) of using Recovery record are that you can repair CRC errors and bit addition/subtraction in RAR Parts without having to download additional PARs. This is particularly valuable if the PARs themselves have been damaged. Thus, in a heavily fracture post in which not enough good PARs are available to get completion, you may be able to Repair enough Parts to enable the remaining PARs to do their job.

Also, to reduce the time it takes you to RAR your post, consider using Store as your compression method, especially if the files are encoded with divx3.

6. Put the ep # before the part count in your binary post's Subject Line

Design your subject line so that the parts of each episode are grouped together. As most here sort by Subject, posts that interleave together, such as...

Foobar [22 of 33] ep 05 - FB05.part
Foobar [22 of 33] ep 06 - FB06.part...
Foobar [23 of 33] ep 05 - FB05.part...
Foobar [23 of 33] ep 06 - FB06.part...
Foobar [24 of 33] ep 05 - FB05.part...

...tend to be very irritating -- consider this a *comfort* nag. This specific case exhibits the most common mistake -- the poster didn't put the ep # before the part count.

...and, remember, keep those subject lines short....

7. When posting a movie or an SVCD (or similar large binary), make it a multi-day post

If you are posting a CD sized file, like a movie or an SVCD, please consider doing a multi-day post, moderating your upload to a rate of ~200-400M per day, and using a subject line syntax like:

Foobar - The Movie, Part 1 - [/sub and encode info/] [Day 1 of 2] [$1/$2] - $F

As group bandwidth is _always_ a limited commodity, not only does posting it all at once reduce general retention and therefore increase incompletions for all posts, those with slower connections that might be grabbing your post just can't keep up, nor can those whose isps might force them to have daily download volume caps. All this just causes more requests for fills/reposts, furthering group congestion.

And even if you don't use the "Day # of #" syntax and want to queue the whole thing at once, and are posting with PP2K, you can use the *File / Hold Files* setting to postpone the transmission of part of your post to the next day(s).

Posters are also encouraged to put their VCD and SVCD binaries in alt.binaries.anime.vcd, with a Notice of the post in aba/abma

8. Please refrain from putting requests in the subject line of binary posts

This one always raises some hackles, unfortunately....

Please refrain from putting requests in the subject line of binary posts. Granted this style is SOP for warez, but things like "Here is Foobar ep 11, please post Gringle ep 23" are just not that great for the health of the group. And, yes, there is a little logic behind this, besides keeping things a bit more organized -- many here use filters when grabbing binaries or checking text. Thus, your post may be inadvertently downloaded by someone who is d/l'd capped (looking for Gringle, they got that hated Foobar, not making them too happy). Or, the reverse, someone may be filtering out all messages with *Gringle*, thus causing them to miss the post of Foobar that they have been waiting for.

Further, this practice makes it _much_ harder for the good folks at AnimeUsenet to do their (volunteer) job, causing errors in what title gets parsed out as the actual post to be entered in the database. And, on a personal note, when I'm running a filter on Easynews web server looking for that episode of Foobar that I missed last month, I'm growing to hate mucking through the endless Foobar requests that people put in their non-Foobar related posts.

Further complaints arise from the fact that it tends to look like always obnoxious v-spam, especially when you lead off with your request. Also, and rather obviously, the practice tends to make for over-long Subject Lines -- something to be routinely avoided.

Where to put your request? How about in the '00' file of your post or in the header of a text reply to your own post. And there is nothing wrong with making a separate standard text request of course.

There is a gray area when considering requests for other episodes of the same series as the episode being posted. It is still not probably a great idea to request this way, but at least some of the objections no longer apply.

9. Post binary tests to alt.binaries.test, not aba/abma

When testing your ability to properly post binaries be sure to make alt.binaries.test your destination, not aba/abma/abmar.

10. Please refrain from HIWIH posts

HIWIH (Here Is What I Have) posts are generally to be avoided in any binary group, as they are not really a very good use of bandwidth. In a HIWIH post, a poster ups all the parts that they have of an incomplete episode, along with an appeal in the subject line to fill those parts that they are missing, making it very like v-spam. Essentially it is a repost of an episode, but guaranteed incomplete before it even starts, thus pretty useless.

11. Before making a request for a fill read any '00' or nfo attached to the post

If you have any questions about a post, especially with regards to fills, be sure to first look at any text messages that were included with the post. You will usually find these as '00' messages or within an 'nfo' attachment.

12. Combine requests for part fills for a given episode into one message

This is not a major issue, but is still worth serious consideration...

Don't make multiple message, single episode fill requests along the lines of:

Req - Kierkegaard Peals Potatos ep 23 part12.rar
Req - Kierkegaard Peals Potatos ep 23 part13.rar
Req - Kierkegaard Peals Potatos ep 23 part14.rar
Req - Kierkegaard Peals Potatos ep 23 part22.rar
Req - Kierkegaard Peals Potatos ep 23 part33.rar
Req - Kierkegaard Peals Potatos ep 23 part45.rar

Instead try something like:

Req - need fills for Kierkegaard Peals Potatos ep 23 parts 12-14,22,33,45

First, your request will look less like v-spam, which most long-timers have habituated themselves into ignoring out-of-hand.

Second, combining your requests will let the poster (or whoever might be doing fills for them) better track who needs what. And anything that eases that burden is by definition *good*.

13. Before posting a new episode check to make sure someone didn't just post it

This applies mainly to new releases from the subbing channels, but really should be done for any post. Just before you start the upload, check aba/abma to make sure someone hasn't started a post of the same _exact_ thing already. Of course, because of server latency (the time period between when a message is posted and when it actually shows on your server), there will still be some duplication of new releases, but at least make a minimum effort to reduce bandwidth wastage.

14. Don't nym-shift

Don't nym-shift. In its most specific (and obnoxous) usage, this means don't post multiple requests under different *nick* names. Even if you are doing it innocently, it still looks like you are changing your name within the groups in order not to look so greedy. Especially frowned on is requesting the same episode multiple times under different author names to make it seem in great demand.

15. Indicate if your post is a Sub, Dub or Raw

To give people information that they can use when evaluating if they want to grab your post, please indicate if it is a Sub, Dub or Raw (Japanese language with no subtitles). And as the vast majority of posts here are either Japanese language with English subtitles or dubbed into English, any other variences from those two catagories should probably also be noted.

Here are a couple of samples with other varying details:

Schindler is Listing ep 21 [dub (Bulgarian), vivo] - yenc - SiL-21.part....


SiL tv 21 [sub, divx3] - yenc - Schindler is Listing And About to Topple 21[].part....

If your post is a Raw, consider putting it in alt.binaries.multimedia.anime.raws or alt.binaries.multimedia.japanese instead of aba/abma/abmar.

16. Use AnimeUsenet to check when/if something has been posted

Want to see when something was posted in the last year and a half? Or check all the titles posted in the last week? Use:

This site is brought to you through the (great) efforts of matt, xo and Gorunova and is an invaluable resource. Use it.

17. Post Dragonball(Z) and Sailormoon in their own groups, not in aba/abma

Dragonball and Sailormoon have their own active binary groups. As such and by long time group usage, they are generally considered off-topic (not to be posted) in aba & abma. Instead use:


Just a note here on the context in which these two animes have been singled out -- alt.binaries.multimedia.sailor-moon actually pre-dates both aba and abma. At that time anime was generally posted to abm and the sailor-moon subgroup was very active. Thus, even at their start SM was rarely posted to aba/abma and it never really has been since.

abd was created as a result of the most torturous flame war aba/abma have had -- eventually the DB/Z fans basically wanted out and the feeling was pretty mutual from general aba/abma users.

18. When posting parts split with HJSplit, be sure to include a checksum for the video file

HJSplit appears to be a tool that may become fairly popular in situations where RARing your post is not an option, but be aware that it currently has no internal error protection against bit damage incurred during Usenet transport. Thus, you might download something that has been damaged and will be able join it, even play it, without anything complaining.

Thus, besides posting a PAR set with your HJSplit processed post, also include a CRC check on the episode itself to further insure the integrity of the final *product*. The easiest route is to generate an SFV for the video file and post it, or copy the CRC that HJSplit can generate into the file name, the post's Subject Line, a '00' file or an 'nfo' file. Granted, while the downloader can do a check on the unjoined parts just by running their PAR utility, it is more then likely that if they apparently have all the parts then HJSplit joins them without a problem and it actually plays, they won't bother. Also an SFV check on the file itself (my preferred solution) further protects you against HJSplit itself generating an error.

19. Please put the video codec in the subject line

Please give at least a general idea of the codec used in the subject line. Just some of the choices are listed in the faq:

20. Do not include things like your post's 'nfo' or 'sfv' in your PAR set

Please don't include the files like an 'nfo' or an 'sfv' in the PAR set of your post, or at least make them "non-recoverable" if you do include them. That way it is not necessary to have them in order to do any PAR based part recovery. This is particularly inconvenient if you used a generic name for an 'nfo' file which could easily be over-written by a later download.

21. Do not archive your post as a self-extracting executable

Granted (Win)RAR can open your 'exe' post just like a regular '.rar' from the *File / Open...* menu, but it is still not advisable to compress your posts as self-extracting executables. The most obvious reason why are worries about viruses -- no one wants to *run* your post by mistake...just in case. It should also be noted that some binary downloading programs filter out 'exe' attachments by default (Newbin for instance), hence your initial Part may not even be seen.

22. If applicable, please include the subber's name on posts/reposts

Frequently, for the *latest & greatest* series, a half dozen different subbing groups may be competing for attention with alternate versions of the same show. And, not surprisingly, many folks are picky about which version of a given show they download. Hence, if applicable, please include the subber's name on posts/reposts, Usually, if the first post is from a regular subbing group, it is pretty obvious. Most of the problems arise on reposts where the poster has repacked the show without including the subber's name in the part file name or as text on the subject line.

23. Limit the length of the Subject Line of your binary post

Limit the length of the Subject Line of your binary post -- put in only what is necessary to enable downloaders to make a clear call as to whether or not they want to grab it (title; ep #; ova/tv/movie; sub/dub; codec; subber if applicable).

What is unnecessary? Some examples:

  • your nick - everyone's newsreader already lists it.
  • requests - covered in an earlier *nag* that is sure to be repeated.
  • any duplicate info
  • advertisements for your irc channel.
  • life stories.
  • ......and I'm sure you can think of 'lots more....

24. Post your PARs after the RARs for max benefit

As people frequently don't realize they need your PAR's until after they've downloaded and tried to unrar your post, give those on low retention servers a better chance of going back and grabbing a PAR or two by posting them after your RAR post and not before.

25. Don't archive multiple episodes into one rar set

Episodes really should be posted as separate RAR sets. The most obvious reason is that if a downloader just needs one of the set you've posted, they don't have to grab all the rest. In this dawning era of d/l caps this can be pretty important.

26. Don't Flood (...the most basic *nag* of them all...)

Please do not Flood posts into aba/abma. As group bandwidth is _always_ a limited commodity, not only does it reduce general retention and therefore increase incompletions for all posts, those with slower connections that might be grabbing your post just can't keep up, nor can those who might have download volume caps instituted by their isp's, regardless of whether the source server is local or premium .

As all this just causes more requests for fills/reposts, furthering group congestion, moderating your post to ~200-400M per day would help everyone, including yourself, just in case your isp monitors your upload rate.

27. NAG suggestions

Have an idea for a NAG? Post your suggestions to