The main thing you need to understand is that what players see in the chat window isn't ever sent or received in the form that it appears. When a player sends a message containing an AudioX sample link, the link part of the message is encoded. Likewise when a recipient recieves an (encoded) link, it's decoded for display. This encoding is required because sending non-standard hyperlinks via the chat system causes a forced disconnect (to stop scammers sending fake item links).



AudioX II alpha.13 and onwards

AudioX currently uses its own format when sending links between players. The format is:

Where

• SOUNDPATH is the full PlaySoundFile pathname. E.g. "Sound\Character\BloodElf\BloodElfMaleHello02.wav".

This means that links can be sent to other AudioX users and, provided the soundpath is valid for World of Warcraft, the linked sample should playback regardless of it's presences in the SoundLib. In otherwords sender and recipient SoundLib's need not be the same, or even present for the purpose of AudioX2 link playback or re-linking.

This allows the seperation of the relatively light-weight business of handling chat links away from the memory intensive business of loading and searching SoundLibs.

It also means that the links aren't entirely meaningless to no AudioX players. They can (with a bit of copy and pasting) play the link back using /script PlaySoundFile("SOUNDPATH").

Third party mod developers can also choose to offer support for the format in their own mods. For example, another chat mod might offer playback facilities for inbound AudioX2 links, without ever needing to concern itself with SoundLibs etc.


Disadvantages

• Decoded Hyperlinks are much longer than the old alpha.1 format. This means that often only one link can be linked into an outbound message.
• Finding the SoundLib index of a specific link requires a search through the SoundLib. This typically only occurs when AudioX-Search has verbose output on.
• Linking soundpaths with more than 114 characters may pose a problem.
  The reason for this is that the ChatFrameEditBox counts the underpinning format of Blizzard hyperlinks in the character count of a given message (which is limited to 256 characters). Given that blizzard links take the format of |cXXXXXXXX|HAudioX2:SOUNDPATH|h[SOUNDPATH]|h|r, the maximum SOUNDPATH without any cropping is (256-28)/2.
  AudioX allows you to reduce the impact of this problem by reducing the size of the second SOUNDPATH occurence by using /ax c <num>. It's also possible to (via /ax f false) to force links to appear in their AudioX2 send format.

Obsolete: AudioX alpha.1 to beta.12 encoded format

AudioX used its own format when sending links between players. The format is:

Where:

• NUMBER is the samples location within the SoundLib array
• CHECKSUM is sum of every character's string.byte value in the SoundLib array encoded into base62 (0-9 A-Z a-z)
• VERSION is the hex value of the AudioX version number

Why CHECKSUM and VERSION?

It's important that sender and recipient have the same version of the SoundLib.lua. If the soundlibs are different then the path for any given index in SoundLib may or (more importantly) may not be the same. That is, the senders Nth sample in the sender's SoundLib might differ from the recipient's Nth sample in the recipient's SoundLib.

CHECKSUM is used to check if a received sample is from a player who is using the same SoundLib. If the SoundLibs differ, VERSION is used to guestimate the cause for the difference and advise on suitable action.


Why this format?

• Link size is kept as small as reasonably possible.
• Generated links are 100% predictable in terms of what characters may be present. There is no risk of escape characters appearing in normal AudioX operation. The same can not be said of Blizzards soundpaths, which are at the whim of Blizzard developers.
• AudioX rarely has to search the SoundLib for a sample. Both encoded and decoded versions of the links contain the index value (decoded links hide the value in the address part of the hyperlink). This means that there's no additional searching required to get the index value. And converting an index value into a path is a simple case of directly addressing the SoundLib array using index as the element address.

Downsides:

• SoundLib has to be loaded.
• Sender and recipient SoundLibs have to be identical. This means a checksum has to be generated once when AudioX loads (quite intensive). The checksum is then used to compare with links sent from other players to check if they are using an identical SoundLib.
• Other mod authors have to work a bit harder to read/write AudioX compatible sound links. They need a copy of the SoundLib.