wN7CAQADAEhmYO10zFJMdNGsdcTejHeRnVVMVsBtMrx0xFa8cTPsdUze/Hpg33VMXuh3k+x3zV7c +WFdd03e3XLRTHXMVsx60iRVz/bFNbMQLu/W5vgyEXqf8vjzkxB+n/bWdNAQL+9+8XLgA3Xfftix 4Hx1zN7jeuDtVUTW3KEQ7HVM1uhZESRVxNbJNdFhXc/6/bZxETVMWfj3c8cnfF3+8TakI1Q+3P+1 RyEkevl2Fex1zfKmh1yO3N+Sz5iCI2RP8tb2diA1X9Lj/fADJlxS6fxwNXXMV/D3giBnfVL++bYg ZV3S9P02IGVf0tz2diA3zd7B+FABN13e2f4RP1VM3vR/0P51zNaoWmKtdc3ejFYT73XM1nZ8kbx1 zNb6f5HfVcxe1Hxh7VXM3v98Ec11zN5bfGLtVExe

hint for decoding:

<paste> | base64 --decode | c2dec 1400 - - | aplay -f S16_LE

(c2dec from codec2)

@Dee Whoa, that is small! Very cool!

@Dee Also, I'm not sure if I'm decoding it right, is there supposed to be a fart at the beginning?

@samgai I might have accidentally left a wav header in, whoops

@samgai actually, no, I didn't. It's an artifact that only happens with base64-encoding, so it might be, I dunno, padding?

@Dee Now I have some new excuses to use in the event of a fart.

@samgai It appears the actual answer is that c2dec detects something or other based on the file extension, and there’s no fart at the start if the extension is .c2, but when you’re reading from stdin you don’t have an extension

@samgai so I guess the fart is a codec 2 header, and it does no header detection if it expects a raw file?

@Dee I think so. The hexdump starts with "c0 de c2", which looks pretty deliberate.

@samgai Ha!

@Dee Maybe you could try to create encoded output without the header, so that it is a bit shorter and results in a fart-free reconstruction.