transmit_frequency_start and stop should probably always be 2-dimensional

[geoffmatt]

This is more preference from my perspective, but I would advise against the following behaviour with regards to the transmit_frequency_start and transmit_frequency_stop variables: "The beam dimension can be omitted, in which case the value apples to all beams in the ping."

I can see why this seems like a good idea because it will reduce the size of these variables for systems where the frequency does not change with beam. However it adds complexity to any reading code and that complexity is very easy to miss, which could lead to unnecessary bugs. When reading the document it states that these variables are Mandatory and 2-D in ping and beam space. This is not actually the case, the variables can be 1-D, but the table only makes this clear in the comment field.

It's especially easy to miss because the other variables which vary with ping and beam, such as transducer_gain do not seem to have this caveat. This is despite exactly the same line of reasoning being appliccable to this variable.

I would urge against adding this sort of behaviour in the format, because it adds unnecessary complexity to any reading code, and with that come bugs.

[gavinmacaulay]

OK, that seems reasonable. We trade-off small increases in file size for less bugs and simpler coding :)

[geoffmatt]

Thanks Gavin, that'd be awesome :)

[gavinmacaulay]

Addressed in PR #57