Join functions

Both enter and join functions restrict the region that the user is allowed to edit (using edit contig) to the region of overlap. 

The join function has exactly the opposite effect of split, taking a delimiter and an array (or list) and returning a scalar containing each of the elements joined together by the delimiter. Thus, continuing the earlier example, the fields array can be turned into a tab-delimited string by joining on the tab character (whose escape symbol is t) ... 

Of course, the very general nature of this algorithm means that there is enormous scope in how we specify the details. In the next sections, we will explore the issues of what features to use, how to formulate the target function, the join function, the issue of the choice of base type and finally search issues. 

Both the target and join functions operate on a feature structure of the units and specification and conveniently we can use the feature structure formalism for both. The Hunt and Black framework doesn t limit the type or nature of the features or their values in any way, so in principle we are able to use any features we want... 

The purpose of the join function is to tell us how well two units will join together when concatenated. In most approaches this function returns a cost, such that we usually talk about join costs. Other formulations are however possible, including the join classifier, which returns true or false, and the join probability, which returns the probability that two units will be found in sequence. 

Another way of improving on the basic acoustic distance join cost is the probabilistic sequence join function, which takes more fi ames into account than just those near the join. Vepa and King [470] used a Kalman filter to model the dynamics of frame evolution, and then converted this into a cost, measured in terms of how far potential joins deviated from this model. A full probabilistic formulation, which avoids the idea of cost altogether was developed by Taylor [438],... 

A more extreme view is to consider the middle region very small, such that we take the view that units either join together well (we can t hear the join) or they don t (we can hear the join). Then, the join cost becomes a function which returns a binary value. Another way of stating this is that the join function is not returning a cost at all, but is in fact a classifier which simply returns true of two units will join and false if they don t. To our knowledge Pantazis et al [345] is the only published study that has examined this approach in detail. In that study, they asked listeners to tell if they eould hear a join or not, and use this to build a classifier which made a decision based on acoustic features. In their study, they used a harmonic model as the acoustic representation (see... 

As with all the studies which directly use perceptual evidence, the amount of data available for training is often very limited due to the high cost of collection. It is possible however to consider classifiers which do not rely on making human judgments. This sequence join classifier has a similar philosophy to the probabilistic sequence join function. We use the fact that our entire speech corpus is composed of large amounts of naturally occurring perfect joins , as every single example of two frames found side by side is an example of such. Therefore we have three situations ... 

If we have N phonemes in our system, we will have 2N half phone base types, and N diphones. Assuming we have on average 500 units for each diphone base type, we would have on average 25 ON units for each half phone base type. Thus if we consider every unit which matches the specification, we now have 250N units at each time slot in the search for half-phones, compared with 500 for diphones, so if A = 40 this means we have, 10000 units, ie 20 times more units at each slot. Given that the join function is calculated over every combination of units at a join, this means that instead of 500 = 250,000 join costs to calculate we now have (250A/) = 100,000,000 joins, 400 times more. These calculations are of course for the same sized database, which means that just by changing the base type, we now have to compute 400 times more join costs. 

The risk of employing the pre-selection technique is that we reduce the number of candidates being considered in the search without taking the join function into account the operation only... 

Here we make some observations about the nature of features and how they are employed in both the target and join functions. Firstly, it is important to note that the term perceptual is often used in a very general manner, which can lead to confusion over what we are actually talking about. The main point is to not confuse any idea of auditory perception with linguistic perception. It is well known that the ear cleverly processes the signals it receives and has a non-linear response over the spectrum. While this can, and perhaps should be modelled, it is important to note that this will only go so far, as on top of this sits an independent linguistic perceptual space which behaves in a quite different manner. 

Two functions, normally defined as costs are used. The target function/cost gives a measure of similarity between specification and unit, and the join function/cost gives a measure of how well two units join. 

The join function tells us how well two units will join. 

Some types of phones class (e.g. fricatives) are easier to join than others (e.g. vowels) and a good join function should account for this. 

An alternative view is to see join functions as classifiers which give us a binary decision as to whether two units will join well. 

An further view is to define the join function as something which gives us a probability of seeing the fi-ames across a join, with the idea that high probability sequences will sound good, and low probability ones will sound bad. 

---