Summarised (and expanded) from comments above:
BibTeX uses the aux file written by LaTeX (showing where you want to cite what) together with a bst file (containing stylistic information - such as plain.bst) and a bib file (containing bibliographic information about any document you might want to reference). So a workflow from the command line might look like
latex - to generate the aux filebibtex - to generate a bbl file which contains information about the specific references mentioned in the aux file, formatted correctlylatex - to incorporate the information in the bbl file into your typeset document- possibly
latex again, to fix any cross-referencing problems introduced when all the citations were included
Looking at the aux and bbl files along the way - and, as @Joseph pointed out, the blg file which is BibTeX's log - can help to troubleshoot problems.
For completeness as an answer: on this occasion it apparently turned out that the bibtex step wasn't working due to a typo in the name of the bst file.
To parse BibTeX format files, Biber uses a C library called "btparse" which is, for all intents and purposes, 99.9% compatible with BibTeX. So, You should rarely have problem using Biber as a drop-in replacement for BibTeX. As mentioned by others, the issue is rather the slightly different data model which biblatex has compared with the data model in BibTeX.
So, your question really relates to the difference in data models between plain BibTeX and BibLaTeX, regardless of whether you are using Biber as the biblatex backend. Be aware that in the future, around BibLaTeX 2.x, BibTeX will no longer be supported as a biblatex backend as it has too many limitations. Of course BibTeX format data files will always be supported.
The more important question is, as you mention, what the advantages of Biber might be even if you are not using any of the biblatex data model specifics. Here are some advantages of Biber in this respect (you can get an idea by searching for the string "Biber only" in the biblatex manual), omitting the features which require data source changes:
- Support of data sources other than
.bib (currently RIS, Zotero RDF/XML, Endnote XML)
- Support for remote data sources (
.bib files available via ftp or http)
- Support of other output formats (in 0.9.8 it will support GraphViz .dot output for
data visualisation and conversion to the planned biblateXML format)
- Full Unicode 6.0 support (including file names and citation keys)
- A sorting mechanism which I think is probably as good or better than any commercial
product - full Unicode, multi-field, per-field case and direction, CLDR aware and
completely user configurable. BibTeX doesn't come close in this regard.
- Automatic name and name list disambiguation. I think this is quite an impressive feature.
See section 4.11.4 of the
biblatex manual for a very good explanation of this with examples.
- Completely customisable crossref inheritance rules. BibTeX has a very basic static rule
only.
- Automatic encoding and decoding, including UTF-8 <-> LaTeX macros
- Very flexible configuration file "sourcemap" option which can be used to change the
.bib data as it is read by Biber, without changing the actual data source itself. You
can use this to do all sorts of things like drop certain fields, add fields,
conditionally drop/add fields, change fields using full Perl 5.14 regular expressions
(see Biber manual section 3.1.2).
This last feature is particularly interesting for you as you can potentially map your pure BibTeX .bib files into the biblatex model on the fly as Biber reads them but without altering the files. It's also very useful for dropping fields like abstract which often cause trouble due to LaTeX reserved characters.
There are also some other features implemented in Biber which are available in BibLaTeX 2.x:
- Customisable labels
- Multiple bibliographies in the same refsection with their own sorting/filtering
- "Related" entries - a general solution to the issue of all these "reprinted as",
"translated as" etc. requirements.
I forgot to mention that Biber automatically applies the BibLaTeX field and entrytype mappings (address -> location etc.) mentioned in the documentation. It does this by implementing some driver-level source mappings (see \DeclareSourcemap and its variants in the biblatex documentation).
Best Answer
I don't know of any Bluebook style, and I think I would if it existed. Given the notorious complexities of the Bluebook it would have to be a biblatex project, and it would be quite a project! In the common law world, I know there is a written-and-working-but-unreleased version of the McGill style for Canadian authorities, there's a partially compete Australian style, and there's an English style based on OSCOLA, which is on CTAN. None of them is Bluebook conformant. The one that I think is closest to complete (which is OSCOLA -- but (disclaimer!) I wrote it so I suffer parental bias) might provide a start -- but it would only be a sort of "inspiration" start, rather than a "much of the legwork is done" start: also it's hardly a stable package.
Implementation of a subset of the Bluebook (say books, articles, cases and perhaps the Constitution and USC) wouldn't probably be too much of a struggle. Implementing the whole thing would be a mammoth task. How mammoth would depend on how far you sought to automate things like abbreviations, cite signals, citation order and the like.