1
$\begingroup$

Can anyone mention me techniques to hide an image in an audio file ?

Thanks

$\endgroup$
4
  • $\begingroup$ i differ with the downvoter and others who wanted to close this question. it's a good question. $\endgroup$ Commented Feb 24, 2015 at 20:49
  • $\begingroup$ Well, no research whatsoever... $\endgroup$
    – jojeck
    Commented Feb 24, 2015 at 21:24
  • $\begingroup$ yeah, you might be right, jo. maybe this is his research. $\endgroup$ Commented Feb 24, 2015 at 21:28
  • $\begingroup$ Sure thing, but anyway that is desirable. $\endgroup$
    – jojeck
    Commented Feb 24, 2015 at 21:46

1 Answer 1

1
$\begingroup$

i dunno if this is a technique oft discussed in the field of steganography, but this is the first technique mentioned for digital data:

you embed your hidden message in the least-significant bit (LSB) of every sample word in the audio. i have used this to hide (from audibility) metadata about the audio. i have, in the past, embedded pitch detection data in the LSB of a stream of 16-bit audio words. the result is that the true audio was really 15-bit and the hidden embeded data (from the POV of audio was random or noisy bits in the LSB) would just sound like a form of added noise, similar to quantization noise (as if the LSB was always zero). to best mask this metadata from the sound, noise-shaping or error-shaping is employed at the 15 bit quantization level.

the result is that your meta-data is a stream of bits, one bit per sample of audio. you'll need to worry about framing and synchronization of that data so you know where the beginning of every meta-data frame is. the way i did it was similar to the old SDLC in that i chose some "magic number" as a prefix (this is in the serial data from the LSBs of the audio words) to mark the beginning of a frame of metadata. say that prefix is 0b11111111, eight 1 bits in a row. if the meta data ever needed to have seven 1 bits in a row, whether or not the next bit was a 1, i would insert an extra 0 into the stream that the receiver knew to take out. each time this would occur in the serial data, this would make the serial stream 1 bit longer for the frame than would otherwise be required. that way eight 1 bits in a row could only mean a frame start marker.

actually i would not use 0b11111111 because it would occur in data often, so i analyzed a stream of actual metadata with a C program to see what 8-bit sequences occurred least often. and of the least common 8-bit sequences i would pick the one with the first 7 bits occurring least often. that would be my choice for a frame marker. whatever was the last bit of that 8-bit marker, i would insert the opposite of that bit if i ever saw the uncommon 7-bit sequence in the stream of data and when the receiver would see the same 7 bits (and it wasn't the 8-bit marker), it would remove that bit from the stream. so there was no possibility of an accidental combination of data falsely screwing up my metadata framing.

so whether this metadata is an image or something else doesn't matter. it's just data. of course, if the audio is compressed or processed in any normal manner, it will kill this metadata unless you strip it out and put it back in after processing.

$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.