Hiding Data In Sound
Вставка
- Опубліковано 18 січ 2023
- In this video, we're learning about steganography: the art of hiding data inside other data.
=[ 🔗 Links 🔗 ]=
💌 Updates to your inbox: tinyletter.com/lowleveljavasc...
🗣 Discord: / discord
⭐️ Patreon: / lowleveljavascript
💻 Github Repo: github.com/lowbyteproductions...
During the encryption process, you can use for example a lorenz attractor, with known parameters to make those bytes statistically random, so even if you have pure black or blue image, in encrypted form it will appear as uniform noise.
15:51 in Python you can use // to do an integer divide which floors it automatically, though it is less explicit than math.floor if you care about self-documenting code.
great video!
Great video! really interesting way to do steganography. It is the first time I have seen it applied to sound/music
Cool video as always francis! What I was wondering was, we worked on mono channel audio in this video, if we can increment the number of channels, the length of the audio file, I assume would become shorter? I know it wouldn't really help with the file size but still it would make the audio length shorter? My idea is to sequentially write the bits in order of the channels.
For example if we were given the binary code 01000001 to encode, using mono channel, we would flip the last two bits present at x second, then we would flip at x+1 second and so on.... I know that's not really it but I'm just trying to demonstrate what I mean :)
So why don't we create an audio with 4 channels, flip the last two bits of the first byte at x second in channel 1, then same in channel two and so on?
Like place 01 in channel 1, 00 in channel 2, 00 in channel 3, 01 in channel 4? They'd be playing simultaneously obviously and a difference would be hard to make out I guess.
thank you for sharing that, so simple and effective :) congrats
Fantastic video! Thank you for your experiment! Your videos are really motivating 👏 🙇♂️
My comment from before seems to have disappeared! Perhaps I accidentally deleted it instead of editing it for the steganography typo?
Anyway in answer to your question, // is always a floor division - however if one of the operands is a float, you’ll get a float result - e.g 10.7 // 2 = 5.0. If you explicitly need that to be an int type you can wrap it up in an int().
If both the operands are already ints, even if the result would’ve been a float by true division, // will produce an int type.
Wow! Was just experimenting with linecoding and AFSK in Web Audio Api :)
Awesome! It would be fun to explore some modulation and DSP techniques on the channel
whoa, new channel name?
excited to watch this!
Yes indeed, it changed a little while back. I made a video explaining it, but the gist is: same content in spirit, but with no restrictions on languages and technologies
I have spent years of my life perfecting my judgement, so seeing this channel and its content has me subscribing almost instantly. I won't watch it yet, but it's in store for later.
Fyi, you can do floored division using a double-slash operator: n // 4
at 22:00 you say that the number is going to be positive when doing this. I'm struggling a bit to see why that is the case.
Say I have x = -5
x in byte representation would be 11111011 (I'm ignoring endianness, which may be why I'm confused?).
And'ing that with 0xfffc would be 11111000 which is now -8.
Or'ing with your bits (10) would 11111010 which is -6.
At what point did the number become positive? If you could please point out where I am making my mistake I would greatly appreciate it.
Python stops interpreting the number as signed after a bitwise operation. So -5 in this case would be seen as 251 instead.
Great video! Though I can't seem to find your video on the WAV file format.
Edit: nvm literally just found it.
Here is a question about something that would be much more complicated. Could you make a symbolic link into the file that points to the hidden data? Like a home brew alternate data streams?
What do you mean? Encode the symbolic link rather than the file? What would be the purpose of that?
I noticed something interesting. As it turns out, with the WAV file you have, a part of the header reads "D[?][?]Xdata", while the WAV I have reads "D[?][?]XLIST", which your script does not like. Any way I could convert my XLIST WAVE into an Xdata WAVE?
The wav file can contain other sections (sub chunks), which usually contain metadata like artist, track name etc. All sub chunks have the same basic layout: 4 byte, big endian ID (list), followed by a uint32 little endian size, and some data of the previously specified size.
So what you can do is to extend the parser to read the riff chunk, and then a list of sub chunks. If the sub chunk isn't a data sub chunk, you can basically just skip it.
Bit of a project, but definitely a good one!
@@LowByteProductions I actually made a script that pretty much removes the metadata, excluding the sample rate and channel count. Now it works flawlessly!
Awesome!
45:46 Yes it does, and it is also the same for ifs, fors, whiles, try/excepts and so on. I have no idea why they haven't removed this annoying "feature" even though it is obviously causing a lot of stupid heisenbugs and has no meaningful use whatsoever
Yeah it makes sense - especially since I didn't f.close() the file!
yes. the f variable persisted from the top of the decode file because you forgot to use f.close()
Hello Mr. Robot!
Hello 🤖