As the manual says, you can translate a raster image to GeoTIFF by specifying the appropriate driver:
gdal_translate -of GTiff in.ext out.tif
Note: In this particular case, ensure that the jpg.aux.xml file that was created when converting from geotiff to jpg is present in the same directory as the image you want to convert. This auxiliary file contains the all the necessary geospatial info and is used by gdal when converting back to geotiff.
I downloaded sample data and took one .dat/.Hdr pair from the archive. Then I had a try with GDAL 3.1.0dev on Windows. This version from the gisinternals comes with a specific driver
gdalinfo --formats |find "SNODAS"
SNODAS -raster- (rov): Snow Data Assimilation System
There is some documentation about the driver at https://gdal.org/drivers/raster/snodas.html
Everything seems to go smoothly with this driver when I just tell to use the .Hdr file as input.
gdalinfo us_ssmv01025SlL00T0024TTNATS2018120105DP001.Hdr
Driver: SNODAS/Snow Data Assimilation System
Files: us_ssmv01025SlL00T0024TTNATS2018120105DP001.Hdr
us_ssmv01025SlL00T0024TTNATS2018120105DP001.dat
Size is 6935, 3351
Coordinate System is:
GEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
Origin = (-124.733333333332993,52.875000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Metadata:
Data_Units=Kilograms per square meter / 10.000000
Description=Scaled Non-snow accumulation, 24-hour total
Stop_Date=2018/12/01 06:00:00
Corner Coordinates:
Upper Left (-124.7333333, 52.8750000) (124d44' 0.00"W, 52d52'30.00"N)
Lower Left (-124.7333333, 24.9500000) (124d44' 0.00"W, 24d57' 0.00"N)
Upper Right ( -66.9416667, 52.8750000) ( 66d56'30.00"W, 52d52'30.00"N)
Lower Right ( -66.9416667, 24.9500000) ( 66d56'30.00"W, 24d57' 0.00"N)
Center ( -95.8375000, 38.9125000) ( 95d50'15.00"W, 38d54'45.00"N)
Band 1 Block=6935x1 Type=Int16, ColorInterp=Undefined
Min=0.000 Max=892.000
NoData Value=-9999
gdal_translate -of GTiff us_ssmv01025SlL00T0024TTNATS2018120105DP001.Hdr us_ssmv01025SlL00T0024TTNATS2018120105DP001.tif
Input file size is 6935, 3351
0...10...20...30...40...50...60...70...80...90...100 - done.
Best Answer
For Windows OS, some GDAL builds from Gisinternals are compiled with the KEA driver as well, see
http://www.gisinternals.com/packageinfo.php?file=release-1800-x64-gdal-2-1-0-mapserver-7-0-1.zip
UPDATE
The KEA driver needs a GDAL version 2.0 or later. The linked file works well with the gisinternals build of GDAL 2.1.0, and the resulting tif seems to be placed in the right spot:
gdalinfo reports:
Driver: KEA/KEA Image Format (.kea)
.Loading the file directly into QGIS 2.14.3, the HDF5 driver is used, but the result is misplaced in Ecuador. My QGIS version is not build with KEA driver support.
Unfortunately, the ubuntugis unstable build of GDAL 2.1.0 does NOT (yet) include the KEA driver. So you have to compile GDAL yourself to get the KEA support for Linux systems. For furher support on that, see https://bitbucket.org/chchrsc/kealib/wiki/Building%20KEA%20on%20Ubuntu
You will definitely run into further problems, see https://askubuntu.com/questions/702145/c-header-files-for-hdf5-are-missing
Copying missing files to the expected folder, or adding folders to search paths will clear the situation, and finally I got Ubuntu Xenial to run GDAL 2.1.0 with the KEA driver:
gdal_translate now creates the same output under Ubuntu as the Windows build does.