Richard

Thanks for the sample dataset. I would suggest you forward this dataset to your Philips Research Collaboration Manager. This is a problem with your DICOM data - not dcm2niix. The dataset specifically lists that it has 62 locations and does not differentiate between the L>R and R>L encoding. The two datasets are stacked based on 2001,100a which ranges from 1..62. I realize that you were expecting two volumes each with 31 slices. However, this is not disambiguated in the DICOM header. I would be happy to help once you can get the headers to reflect the unique properties of the scans (just like dcm2niix is already able to disambiguate the different echoes in this sequence). We are at the mercy of the vendors with this - if they tell us that these images belong in a stack of 62 slices, that is what the software will produce. A simple script should help you rescue the exisitng data. I wonder if there is a simple method to ensure future data saves the phase encodings as two different series (ideally with two protocol names). That would solve your issue.
Slices report
(2001,1018) SL 62 //LocationsInAcquisition' % 'NumberOfSlicesMR
Different slices report positions 1..62
(2001,100a) IS [1] SliceNumberMR
...
(2001,100a) IS [62]