Extracting sound samples from the bin files

[Tomasz-1303413]

Sorry if this is a bit technical or off topic. I'm hoping there are others on here that might be interested in this or have technical ability to assist.

I've examined a few of the profile binary files trying to understand how the sounds are stored within. The files are 8MB in size, so not a huge amount of information can be stored. I'd guess that the sound samples are stored at fairly low resolution, probably 8000Hz single channel. I can say with some certainty that they are not stored as raw waveforms. Looking at a spectrum analyzer doesn't show much of a waveform pattern, mostly just random data noise. Most likely some sort of compression is utilized to fit the data within the 8MB capacity. 

Not sure if Hornby technical staff reads these forums, or if they are allowed to provide such info, but any information about the format would be helpful. If I can extract the sound samples, I can provide audio playback without having to go thru the lengthy process of loading each profile into the decoder. This would be of great benefit for those of us trying to find appropriate profiles to use in non-UK locos. 

Thanks,  

Tomasz

[Pendragon Sailing]

Being able to sample the profiles before loading to the decoder would indeed be a helpful addition.
Perhaps this is something that could be built into the HMDCC App, in due course? 

[ntpntpntp]

Copyright issues?  I doubt Hornby would be too keen on someone extracting the sounds they've probably paid money to have recorded, edited and encoded.

Edited August 27 by ntpntpntp

[SteveM6]

I very much suspect that the sound files produced by Hornby would be viewed as being their own intellectual property.

Not something that should be tampered with given they would be protected by copyright law.

Tomasz - just because you can does not mean that you should.

[ColinB]

2 hours ago, Tomasz-1303413 said:

Sorry if this is a bit technical or off topic. I'm hoping there are others on here that might be interested in this or have technical ability to assist.

I've examined a few of the profile binary files trying to understand how the sounds are stored within. The files are 8MB in size, so not a huge amount of information can be stored. I'd guess that the sound samples are stored at fairly low resolution, probably 8000Hz single channel. I can say with some certainty that they are not stored as raw waveforms. Looking at a spectrum analyzer doesn't show much of a waveform pattern, mostly just random data noise. Most likely some sort of compression is utilized to fit the data within the 8MB capacity. 

Not sure if Hornby technical staff reads these forums, or if they are allowed to provide such info, but any information about the format would be helpful. If I can extract the sound samples, I can provide audio playback without having to go thru the lengthy process of loading each profile into the decoder. This would be of great benefit for those of us trying to find appropriate profiles to use in non-UK locos. 

Thanks,  

Tomasz

That is really interesting information. Thank you.

[Tomasz-1303413]

I can appreciate concerns for copyrights, etc. but I also believe that Hornby is sitting on a potential gold mine right now. Let me explain. 

Currently there are only two companies in the world with Bluetooth capable decoders, SoundTraxx being the other one. Hornby has a market advantage by providing more form factors and much better pricing. However, by limiting sound support to their own UK specific models, large international markets are being left untapped. Of course, I'm not advocating for Hornby to produce sound profiles for all the models in existence, that would be a huge task that I'm sure Hornby has no finances or staff to support. However, by making the sound pack format open source there could be an aftermarket support for custom sound packs and converters being created. 

This is not as wild of an idea as it seems on the surface. ESU for example not only has their sound packs available for download on their website https://projects.esu.eu/ but also their file format is well documented and there are several independent shops that can create custom sound packs for their decoders, with the usual disclaimer about voided warranties and such. 

Imagine the customer influx if Hornby were to cooperate with likes of ESU and together release a profile converter that would allow any of the 100s of existing sound packs to be loaded onto the Hornby decoders.  

But back to reality. I'm not out to reverse engineer Hornby products or steal their proprietary sounds, my goal was simply to provide a quick preview of the individual sounds outside of having to load them into a decoder. Having not found a quick and easy way to do so, I won't be spending more resources on this effort. I was hoping maybe someone out there already had the answers I was seeking or maybe will in the future. 

Cheers,

Tomasz

[96RAF]

Having an on-site sampler for each profile was mooted way back in the TTS days and although some samples were available on the odd product page, not all sounds were provided for each profile nor were all profiles made available. The request was passed across for continuance when TXS was being launched but the samples never made it on site. A pity really as like you say it would be useful to listen to the basic sound profile for each loco type.

[nigeb]

On 28/08/2024 at 14:07, Tomasz-1303413 said:

I can appreciate concerns for copyrights, etc. but I also believe that Hornby is sitting on a potential gold mine right now. Let me explain. 

Currently there are only two companies in the world with Bluetooth capable decoders, SoundTraxx being the other one. Hornby has a market advantage by providing more form factors and much better pricing. However, by limiting sound support to their own UK specific models, large international markets are being left untapped. Of course, I'm not advocating for Hornby to produce sound profiles for all the models in existence, that would be a huge task that I'm sure Hornby has no finances or staff to support. However, by making the sound pack format open source there could be an aftermarket support for custom sound packs and converters being created. 

This is not as wild of an idea as it seems on the surface. ESU for example not only has their sound packs available for download on their website https://projects.esu.eu/ but also their file format is well documented and there are several independent shops that can create custom sound packs for their decoders, with the usual disclaimer about voided warranties and such. 

Imagine the customer influx if Hornby were to cooperate with likes of ESU and together release a profile converter that would allow any of the 100s of existing sound packs to be loaded onto the Hornby decoders.  

But back to reality. I'm not out to reverse engineer Hornby products or steal their proprietary sounds, my goal was simply to provide a quick preview of the individual sounds outside of having to load them into a decoder. Having not found a quick and easy way to do so, I won't be spending more resources on this effort. I was hoping maybe someone out there already had the answers I was seeking or maybe will in the future. 

Cheers,

Tomasz

Hi Tomasz, I have and use the ESU sound programmer and found it really useful so I agree with your sentiment.

I also completely agree that we should not be trying to reverse engineer any manufacturer's intellectual property. What I really would like to see though is support for other models and the capability to create my own sound profiles and import them.  I have a few non-UK models such as US Big Boy which would be good to be able to fit a TXS to as the price point is very competitive. Since Hornby appear to be increasingly targeting more serious modelling than the railroad 'toy' market it would be good to see a stronger commitment to this type of development and I'm sure it wouldn't hurt their market share.

There's been a very strong move toward open standards in the computer industry, which included DCC, over the years and it's clear that companies that embrace these open standards can be very successful. Hornby's own Zero1 system was overtaken by DCC, but they're stronger with DCC. Developing open standards, like MP3 in music, for DCC sound and other capabilities, while still providing protection for intellectual property owners like Hornby will eventually reduce costs and everyone will benefit from the flexibility.

[Tomasz-1303413]

A bit more info on this topic. Taking a close look at the decoders the chip installed is Nuvoton NuVoice N570S64A, which according to the manufacturer is a Cortex-M0 ARM CPU with following specs:

So there is a 64KB APROM that gets flashed with the aprom bin file and a 64Mbit (8MB) flash memory that gets flashed with the spirom bin file. According to the specs the sounds are stored at 8KHz sampling rate, but what caught my attention is that the storage duration is 8000 seconds, which means each sample is a single bit of data (8Kx8K=64M). Obviously you can't store raw wave data in one bit per sample, so the question remains how is the sound stored in the flash memory and in the file (since the file is just an image of the flash memory). 

Also, I realized looking at the decoders that the 8 pin and nxt18 decoders are exactly the same except one has the nxt18 socket and the other just has the 8 pin leads soldered to the board. If you look at the 8 pin decoder board you can see there the nxt18 socket can be soldered on. It's possible to convert one to the other, although I don't know why anyone would try. 

Edited September 6 by Tomasz-1303413

[Tomasz-1303413]

A bit more digging on the Nuvoton site I found that the audio is stored in a 5-bit MDPCM (Modified Differential Pulse Code Modulation) algorithm, which doesn't really say much since the "Modified" part seems to be their own technology. 

 

[What About The Bee]

Hi @Tomasz-1303413

Just my two cents and a random thought. 

While your milage may vary, I do not think they mean the column heading as a division.  That is, the user may have a maximum duration of 8000 seconds OR an 8KHz sampling rate (for a much shorter duration).  Trading duration for high fidelity.  Specsmanship, pure and simple.

You could simply ask the chip manufacturer for the "5 bit MDPCM" encryption scheme.  I see no reason for them to hide this 

Bee

Edited September 6 by What About The Bee

[96RAF]

Until you have the protocol for the OS used by TXS and the sound file format you really are wasting you time, interesting tho' the discussion is.

[What About The Bee]

41 minutes ago, 96RAF said:

 the sound file format 

Is the 5 Bit MDPCM.  A quick internet search shows it is readily available on the internet.

The only remaining trick will be the internal "file" format.  I suspect there is a partition that has a pointer to the files within memory.  Each file may have a length and the file may have an EOF marker. Perhaps a frequency denotation for fidelity.

If humans can decrypt Enigma, then perhaps Tomaz can read the sound file.  Its a non trivial task.  Its not something I would spend time on, but to each his own.

Bee

[ColinB]

We used to do compression on our files now I don't know if it relevant but basically you read the file of data. It will be a series of double hex numbers (the representation of a byte of data). So what you do is find repeated patterns. You then replace any occurrence of the pattern with an identifying byte that says this no longer is data but a pointer to a previous pattern and a number, which is the pattern number. I could probably dig out my code, I can't remember the exact format, but obviously it only works is you have repeated patterns of hex bytes which you get in a program. Probably it works the same with sound because I suspect when digitised the data will repeat itself. It only works if the pattern length is greater than the number of bytes that tell the system it is a repeated pattern. I can't remember what sort of compression you get but it is quite good. As in our case it compressed the data significantly. When you want the original data you do the reverse, so if you read a byte saying it is a previous pattern you look up the number and substitute the relevant bytes.

Edited September 6 by ColinB

[What About The Bee]

Hi Colin

The sounds in the Hornby sound file may very well be compressed.  Its a distinct possibility.  That would be a detailed feature on top of the basic structure however. 

It is unknown if 64Mbit of flash is overkill to express the fullness of all the (ahem) bells and whistles. 🙂  If not, sure, compression.  

Tomaz is still at the starting gate.  I wish him luck

Bee

[96RAF]

If you go on the ESU site and download their example sound files and have a play with the build, you will see there is usually a start sound, a body sound which repeats and an end sound. Obviously they can be and usually are, much more complex than that, but what is being attempted here is extracting those sound bytes and trying to work out how to substitute them with custom bytes of your own.

[ColinB]

11 minutes ago, 96RAF said:

If you go on the ESU site and download their example sound files and have a play with the build, you will see there is usually a start sound, a body sound which repeats and an end sound. Obviously they can be and usually are, much more complex than that, but what is being attempted here is extracting those sound bytes and trying to work out how to substitute them with custom bytes of your own.

And somewhere in there there will be a function lookup table that identifies which sound goes with which function. There are loads of ways you can do it.

[Tomasz-1303413]

On 06/09/2024 at 17:28, What About The Bee said:

Is the 5 Bit MDPCM.  A quick internet search shows it is readily available on the internet.

Please share where it's available, most of the results I get are from Nuvoton or sellers of their chips, So far I have not found anything that suggest this is indeed a standard way of encoding audio or a ready made decoder, library, dll, source, etc. 

On 07/09/2024 at 03:13, ColinB said:

And somewhere in there there will be a function lookup table that identifies which sound goes with which function. There are loads of ways you can do it.

I'd guess that's in the aprom file along with other settings/instructions. 

[ColinB]

2 hours ago, Tomasz-1303413 said:

Please share where it's available, most of the results I get are from Nuvoton or sellers of their chips, So far I have not found anything that suggest this is indeed a standard way of encoding audio or a ready made decoder, library, dll, source, etc. 

I'd guess that's in the aprom file along with other settings/instructions. 

I haven't studied the HM7000 that much but perhaps aprom stands for application prom (main program) and I think I saw spirom when it was downloading data, so does it contain more memory available via the spi interface (possibly all the sound data). I must admit I have no intention of second guessing their circuit before the usual people jump in. If you are familiar with microprocessor interrupt vector tables I assume that is how the functions are implemented. I just buy the product and hope they did a reasonable job.

[LTSR_NSE]

1 hour ago, ColinB said:

I just buy the product and hope they did a reasonable job.

Pretty sure 99% of HM7k users agree with you there Colin! 👍

[96RAF]

8 hours ago, ColinB said:

I haven't studied the HM7000 that much but perhaps aprom stands for application prom (main program) and I think I saw spirom when it was downloading data, so does it contain more memory available via the spi interface (possibly all the sound data). I must admit I have no intention of second guessing their circuit before the usual people jump in. If you are familiar with microprocessor interrupt vector tables I assume that is how the functions are implemented. I just buy the product and hope they did a reasonable job.

I suggest reading the famous manual to find out what they are . . .

 

[ColinB]

17 minutes ago, 96RAF said:

I suggest reading the famous manual to find out what they are . . .

 

Thanks RAF. Standard stuff that is basically how an automotive module works except LDROM is called the primary bootloader.

[ColinB]

If the device is using SPI based memory to store the sound files that would explain the long load times when programming it from the App. 

[Tomasz-1303413]

The custom decoder is not 100% accurate yet, still working out some of the control parameters, so the quality is not that great, but here are some random horn samples extracted from a random profile bin file. Sounds like success to me 😄

 

 

[Tomasz-1303413]

Ok guys, I added the ability to preview the profile sounds to the stick thread on top of this forum. The quality is rough because I'm guessing at some of the decoding parameters, but at least you can hear what each profile contains. Hoping this will get better if I have time to work on it some more or if a helpful soul provides me some of the info I'm missing, but for now this'll have to do.