Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer of 32 bit float, and has BID ENDIAN (Power PC) byte order. before the data in the fid file is a file header, and before each block of data e.g. 2D increment) is a block header. The format of the actual data is specified by the status word in the block header - and is always correct.

I've worked with the Bruker format for so long that I don't remmber what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters.

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer of 32 bit float, and has BID ENDIAN (Power PC) byte order. before the data in the fid file is a file header, and before each block of data e.g. 2D increment) is a block header. The format of the actual data is specified by the status word in the block header - and is always correct.

I've worked with the Bruker format for so long that I don't remmber what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters.parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D it is important to note that each block starts on a 512 byte disk-sector boundary.

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer of or 32 bit float, and has BID ENDIAN (Power PC) byte order. before Before the data in the fid file is a file header, and before each block of data e.g. (e.g. 2D increment) is a block header. The format of the actual data is specified by the status word in the block header - and is always correct.correct. The block header is there even if there is only one block.

I've worked with the Bruker format for so long that I don't remmber remember what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data are 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D multi-D, it is important to note that each block starts on a 512 byte disk-sector boundary.boundary. This will almost always be the case. It will not be the case if the TD parameter is some strange value like 741 points. There is no spectroscopic reason why you couldn't have a TD value like 741, and if you do you would have to read the next block starting in the next disk-sector boundary. I think this may be a hold-over from a time when they used to have their own high speed "BFS" file system on the X32. Reading Bruker 1D processed data is straight forward. Reading processed 2D can be a bit trickier because of the sub-matrix format used. (Something like Sparky).

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer or 32 bit float, and has BID ENDIAN (Power PC) byte order. Before the data in the fid file is a file header, and before each block of data (e.g. 2D increment) is a block header. The format of the actual data is specified by the status word in the block header - and is always correct. e.g. FH-BH-data-BH-data-BH-data-BH-data... etc. The block header is there even if there is only one block.

I've worked with the Bruker format for so long that I don't remember what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data are 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D, it is important to note that each block starts on a 512 byte disk-sector boundary. This will almost always be the case. It will not be the case if the TD parameter is some strange value like 741 points. There is no spectroscopic reason why you couldn't have a TD value like 741, and if you do you would have to read the next block starting in the next disk-sector boundary. I think this may be a hold-over from a time when they used to have their own high speed "BFS" file system on the X32. Reading Bruker 1D processed data is straight forward. Reading processed 2D can be a bit trickier because of the sub-matrix format used. (Something like Sparky).

I am willing to share source code for reading Bruker and Varian data to anyone who wants it. This would be a bit newer than the stuff posted on the ftp site.

For a really tough multi-D data format, try JEOL (no flames please!)

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer or 32 bit float, and has BID ENDIAN (Power PC) byte order. Before the data in the fid file is a file header, and before each block of data (e.g. 2D increment) is a block header. e.g. FH-BH-data-BH-data-BH-data-BH-data... etc. The format of the actual data is specified by the status word in the block header - and is always correct. e.g. FH-BH-data-BH-data-BH-data-BH-data... etc. The block header is there even if there is only one block.

I've worked with the Bruker format for so long that I don't remember what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data are 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D, it is important to note that each block starts on a 512 byte disk-sector boundary. This will almost always be the case. It will not be the case if the TD parameter is some strange value like 741 points. There is no spectroscopic reason why you couldn't have a TD value like 741, and if you do you would have to read the next block starting in the next disk-sector boundary. I think this may be a hold-over from a time when they used to have their own high speed "BFS" file system on the X32. Reading Bruker 1D processed data is straight forward. Reading processed 2D can be a bit trickier because of the sub-matrix format used. (Something like Sparky).

I am willing to share source code for reading Bruker and Varian data to anyone who wants it. This would be a bit newer than the stuff posted on the ftp site.

For a really tough multi-D data format, try JEOL (no flames please!)

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer or 32 bit float, and has BID ENDIAN (Power PC) byte order. Before the data in the fid file is a file header, and before each block of data (e.g. 2D increment) is a block header. e.g. FH-BH-data-BH-data-BH-data-BH-data... etc. The format of the actual data is specified by the status word in the block header - and is always correct. The block header is there even if there is only one block.

I've worked with the Bruker format for so long that I don't remember what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data are 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D, it is important to note that each block starts on a 512 byte disk-sector boundary. This It will almost always be the case. It case that the previous block will end at the sector boundary, so that you can just sequentially read the data. This will not be the case if the TD parameter is some strange value like 741 points. There is no spectroscopic reason why you couldn't have a TD value like 741, and if you do you would have to read the next block starting in the next disk-sector boundary. I think this may be a hold-over from a time when they used to have their own high speed "BFS" file system on the X32. Reading Bruker 1D processed data is straight forward. Reading processed 2D can be a bit trickier because of the sub-matrix format used. (Something like Sparky).

I am willing to share source code for reading Bruker and Varian data to anyone who wants it. This would be a bit newer than the stuff posted on the ftp site.

For a really tough multi-D data format, try JEOL (no flames please!)

Varian's data format is well described in their User Programming Manual. The parameters are in the ASCII procar file, and the data in the fid file. The fid can be 32 bit integer, 16 bit integer or 32 bit float, and has BID ENDIAN (Power PC) byte order. Before the data in the fid file is a file header, and before each block of data (e.g. 2D increment) is a block header. e.g. FH-BH-data-BH-data-BH-data-BH-data... etc. The format of the actual data is specified by the status word in the block header - and is always correct. The block header is there even if there is only one block.

I've worked with the Bruker format for so long that I don't remember what manual it is in. The parameters are all in ASCII files (in essentially JCAMP-DX format), with the most relevant ones being the acqus and acqus2, acqus3.... files. These are the status acquisition parameters in the direct and indirect dimensions. You might also want the proc, proc2, etc files for some processing and referencing parameters. The data are in the fid or ser (for multi D) files. There are no block or file headers, but the byte order can be either BIG ENDIAN or LITTLE ENDIAN depending on the host computer used (X32,SGI or PC). This is specified by the BYTORDA acquisition parameter. There is a similar BYTORDP parameter for processed data. The data are 32 bit signed integers. However, I have heard that newer Bruker systems can use 64 bit floating point numbers in some cases. I haven't run across any yet, but I'll have to give it a try when our new Avance III systems arrive. For multi-D, it is important to note that each block starts on a 512 1024 byte disk-sector boundary. It will almost always be the case that the previous block will end at the sector boundary, so that you can just sequentially read the data. This will not be the case if the TD parameter is some strange value like 741 points. There is no spectroscopic reason why you couldn't have a TD value like 741, and if you do you would have to read the next block starting in the next disk-sector boundary. I think this may be a hold-over from a time when they used to have their own high speed "BFS" file system on the X32. Reading Bruker 1D processed data is straight forward. Reading processed 2D can be a bit trickier because of the sub-matrix format used. (Something like Sparky).

I am willing to share source code for reading Bruker and Varian data to anyone who wants it. This would be a bit newer than the stuff posted on the ftp site.

For a really tough multi-D data format, try JEOL (no flames please!)