Includes a number of changes, some more significant than others.

(I apologize for the big CL, I should have been committing and pushing these incrementally.)

1. PitchExtractor now also returns the strength of the pitch candidate, not just the hertz value.

2. The Villing Syllabifier has updated default parameters.  This leads to a much more accurate syllabification routine.

3. ContourFeatureExtractor no longer also includes region- or context-normalized features.  These need to be registered and extracted separately.

4. The 'contour' features -- pitch, intensity, etc. -- used to be cut down to size before being attached to each region.  This made extracting temporally based windows of features challenging, and in some cases impossible.  Now each point in a region contains a pointer to the full region, and each feature extractor is responsible for cutting to the right sized window.  (There might be some efficiency to be gained by caching previously constructed subregions, but this may be more trouble than it's worth.)  This change is the source of many of the changes in this CL.

Just a heads up.  The next significant update will be a move away from the current feature registry system.  This is a fairly significant source of memory bloat and ugly code.  I'm still playing with a few different ways of handling this, but feature extraction will still be driven by feature names.
Major Update. -- Version 1.4

This CL revisits the idea of how AuToBI extracts features.  Under the previous approach every FeatureExtractor that might be needed to be created and registered by AuToBI prior to calling feature extraction.  This was done using a beast of a function called AuToBI.registerAllFeatureExtractors() (aka "the enemy").  This resulted in creating a few hundred objects some of which were never touched again.

The problem here was that there was no way to know at runtime what feature extractors were available, and what features they provided and needed.  The simplest way to itemize the interdependency between features was to create the functionality to extract them, and let them sit around until they were needed.

The solution this CL uses is to force two changes to all FeatureExtractors.

1) every FeatureExtractor needs to include a public static final String "moniker" which describes what features is provides.  FeatureExtractors that provide more than one feature can use a comma separated string to describe each of the provided features.
2) all features have a uniform naming scheme.  moniker[param1,param2,...,paramN].  If a feature doesn't require any parameters, the brackets are removed.
3) every FeatureExtractor must include a constructor that takes only String parameters.

Note that 'moniker' is different than 'extracted_features'.  An extracted feature is the full name, including parameters, for example "log[f0]" and "log[I]" are different features, but share the "log" moniker.

These three modification allow the use of reflection to identify all available FeatureExtractors in a package.  By default AuToBI searches edu.cuny.qc.speech.AuToBI.featureextractors, but there's no restriction on where a user can point the moniker map registration.  This lowers the entry to include new FeatureExtractors.  If a user package contains an FeatureExtractor, it will be discovered without the user needing to register every possible parameter to AuToBI.

Secondly, the unified naming of extracted features and requirement of a String based constructor makes it possible to call any FeatureExtractor constructor at runtime.  This allows AuToBI to construct and register the necessary feature extractors at runtime, driven by the features desired by the user, as determined by the requested features in a FeatureSet object.

AuToBI v1.3.

/* package/MyFancyFeatureExtractor.java */
public class MyFancyFeatureExtractor extends FeatureExtractor { ... }

/* MyMain */
for (String acoustic_feature : new String[]{"log[f0]", "f0", "znormC[log[f0]]", ..., etc."}) {
   registerFeatureExtractor(new MyFancyFeatureExtractor(acoustic_feature);  // potentially creating hundreds of instances, and requiring the user to know the AuToBI guts well enough to enumerate all possible acoustic features
}

AuToBI v1.4

/* package/MyFancyFeatureExtractor.java */
public class MyFancyFeatureExtractor extends FeatureExtractor {
  public static final String moniker = "fancy";
... }

/* MyMain */
registerMonikerMap("package");  // no construction until extractFeatures(FeatureSet) is called.

As the feature naming routine has been reorganized, new models are required as well.  In generating these new models I found that the intermediate phrase boundary classifier had 2 problems - 1. it was very slow. (It used a class-weighted weka Logistic classifier) and 2. it was distinguishing no-boundary, from intermediate-boundary AND intonational-boundary.  And it's only meant to distinguish no-boundary vs. intermediate-boundary.  The second was a simple fix. The first was solved by using LibLinear's L2-regularized logistic regression with class weighting.  This is much much faster.  I will likely move away from all weka classifiers over the summer.

Note:  This has left a class of feature extractors not adhering to the new feature naming requirements.  These feature extractors require some resource that can't be (currently) indicated via a String argument.  These are generally classifiers or other objects that are either created in code or (more often) serialized.  There are two approaches that could be used to address this: 1) require serialization and use a path as the feature indicator, letting the feature extractor handle reading the object from disk. 2) include a resource map which allows for an arbitrary resource to be held by AuToBI and referenced later via "resource[id]" - when the FeatureExtractor is constructed, the object can be retrieved and appropriately attached.    I'm leaning toward the serialization approach for the string based constructor -- if objects need to be attached to an instantiated feature extractor, this FE can still be constructed and registered with AuToBI directly as in v1.3.

However, the v1.3 approach is still operational, the String based moniker approach wraps around it.  For these Feature Extractors, the appropriate mechanism is to construct them "by hand" and register the feature extractors using registerFeatureExtractor(new FeatureExtractor(...));