[RELEASE] Cock Hero: '2019: A Sperm Odyssey'

[3xTripleXXX]

I'm not going to say this definitely works, but two releases ago, my video got taken down after being featured on PH, but when I reuploaded it with the video flipped horizontally, it did not. My latest, I both flipped horizontally and cropped away the studio logos, and it made it through being featured without any takedown notices, and is still up a few months later.

I'm not going to claim that it's safe because of it, since my evidence is anecdotal and on a tiny sample set, but I'm following that same strategy for the one I'm working on now.

I suspect most of the takedown recognition is done through automation, on either recognizing the actual footage, or by keying in on the studio logos, so that should hopefully mess with both of them.

[MacSharpy]

Finally played this one. For a first attempt, I'm very impressed! I was a big fan of your choices of stars and scenes. You reused a lot of girls in multiple rounds, which worked for me as I really like all of the ones reused (Remy, Mia, Jada, Madison Ivy, etc). You did add an element of unpredictability I liked in not always switching between girls in the order they're introduced. A lot of CHs will introduce girls then keep them 1 then 2 then 3 then 4 then 1, etc. I also really love that you showed a preview of one of the girls in the coming round during breaks. I'm not a fan of breaks and stroke through them anyway unless I need the break, but my favorite way for them to be handled if they are there is the way you did. I wasn't as big into some of your music choices. Personally I prefer more EDM style than pop or rap and especially tend to not like usage of songs featuring heavy male vocalists during CHs. Not a deal breaker, just a preference. I still thought this was extremely good, especially when you consider it's your first. I'm sure this took a lot of time and effort so I'm not going to expect anything, but I hope to see you make another one at some point! I really liked this one!

[Retrolove]

I think I'm going to agree with MacSharpy here about most instances. The scenes, the girls, the audio-visual syncronizing - it all worked for me perfectly. Savored every minute of this beautiful CH piece. Thanks a million! Would love to see your production in the future.

[pocetsize]

The downloads all provide lines on the screen Only seconds of watchable content exists between the lines. I've downloaded it compressed and normal from mega and just finished the torrent download.

[high_octane]

The downloads all provide lines on the screen Only seconds of watchable content exists between the lines. I've downloaded it compressed and normal from mega and just finished the torrent download.

Hi, pocetsize!

Could provide me with a checksum of the file you downloaded? If you don't have individual command-line checksum programs, and have 7-Zip installed, all you need to do is right-click on the file, mouse over "CRC SHA", and select "SHA-256" That would help me determine of it is corrupted or not. Compare the result to this:

Code: Select all

SHA256: 36BDC06FF04B77A3F2976F8C0A399617A3D1355C8BC13E3FBAADC54A044A1ABC

Otherwise, maybe you have a faulty decoder or something... I don't really know. I don't use VLC any more, but I just tested it out with this CH, and it works as expected. I encoded the video with H.264 (x.264), so it should work fine on any video player.

[book_guy]

Hmm. 7-Zip generates these various checksums (using your procedure) for me ...

Code: Select all

CRC32: 8AD883D5
CRC64: 9F83451E7352B150
SHA256: E80A4776FB7CE2A0EB960ABE9C8E36479271DD5F5AA8B97F886F737B759D499B
SHA1: DF1B440C84BA69A6D026F83821942A49D673E72D
BLAKE2sp: 19C331C9ED096FC296CA863621BEEF23BB14C89D28B5042001B37C461EB06FE1

... none of which seem to bear any relation to yours. Can't recall if I got this file via the Torrent or the Mega link in this thread. The file plays just fine for me (and I enjoyed it very much thank you!). Culprit? I am suspicious of Mega and their native decoding procedures. They're always messing with "normal" things to get a leg up on ... uh ... reality?

[high_octane]

Hmm. 7-Zip generates these various checksums (using your procedure) for me ...

Code: Select all

CRC32: 8AD883D5
CRC64: 9F83451E7352B150
SHA256: E80A4776FB7CE2A0EB960ABE9C8E36479271DD5F5AA8B97F886F737B759D499B
SHA1: DF1B440C84BA69A6D026F83821942A49D673E72D
BLAKE2sp: 19C331C9ED096FC296CA863621BEEF23BB14C89D28B5042001B37C461EB06FE1

... none of which seem to bear any relation to yours. Can't recall if I got this file via the Torrent or the Mega link in this thread. The file plays just fine for me (and I enjoyed it very much thank you!). Culprit? I am suspicious of Mega and their native decoding procedures. They're always messing with "normal" things to get a leg up on ... uh ... reality?

That's odd. I just downloaded the file from Mega and the checksum is the same as the one I posted, so I'm not sure why you have a different result. Are you sure you used the correct file, and not some other CH by mistake? What does it say the file size is?

[zingg2]

Just checked the sha256sum of the file I downloaded and built the torrent from: 36bdc06ff04b77a3f2976f8c0a399617a3d1355c8bc13e3fbaadc54a044a1abc (i.e. same as high_octane sees).

[HollandXH]

Finally played this one. For a first attempt, I'm very impressed! I was a big fan of your choices of stars and scenes. You reused a lot of girls in multiple rounds, which worked for me as I really like all of the ones reused (Remy, Mia, Jada, Madison Ivy, etc). You did add an element of unpredictability I liked in not always switching between girls in the order they're introduced. A lot of CHs will introduce girls then keep them 1 then 2 then 3 then 4 then 1, etc. I also really love that you showed a preview of one of the girls in the coming round during breaks. I'm not a fan of breaks and stroke through them anyway unless I need the break, but my favorite way for them to be handled if they are there is the way you did. I wasn't as big into some of your music choices. Personally I prefer more EDM style than pop or rap and especially tend to not like usage of songs featuring heavy male vocalists during CHs. Not a deal breaker, just a preference. I still thought this was extremely good, especially when you consider it's your first. I'm sure this took a lot of time and effort so I'm not going to expect anything, but I hope to see you make another one at some point! I really liked this one!

I think I'm going to agree with MacSharpy here about most instances. The scenes, the girls, the audio-visual syncronizing - it all worked for me perfectly. Savored every minute of this beautiful CH piece. Thanks a million! Would love to see your production in the future.

Thanks so much! I always liked the Cock Heros who had a small core of reoccuring girls (in this case Remy Lacroix, Mia Malkova, Sheena Shaw, Aidra Fox) and 'one offs' that'd fit the mood of the round (like Mandy Muse, Gianna Michaels and Casey Calvert).

As for the music, I never thought about including only female vocals. I'm not bothered by it, but I guess it makes a lot of sense for most people. EDM works great as well, but I always liked the edge that R&B and Rap gives.

And another Cock Hero in the future? Maybe, just maybe ;). I have some small ideas here and there, but after two years of making this one (with some large breaks in between, to be fair) I'm just not too sure ;)

[HollandXH]

The downloads all provide lines on the screen Only seconds of watchable content exists between the lines. I've downloaded it compressed and normal from mega and just finished the torrent download.

I have no idea how this happened, but it sucks to see that. I've never worked with Mega before and don't have a lot fo technological knowledge, so hopefully others can help you with this!

[book_guy]

That's odd. ... Are you sure you used the correct file, and not some other CH by mistake? What does it say the file size is?

I just replicated my previous results by using the wrong file, "CH World Championship 2019", doh. Pro'lly got confused by the "2019" in the title.

Spoiler: show

Code: Select all

Name: CHWC2019_FINAL_V01.mp4
Size: 2718295791 bytes (2592 MiB)
CRC32: 8AD883D5
CRC64: 9F83451E7352B150
SHA256: E80A4776FB7CE2A0EB960ABE9C8E36479271DD5F5AA8B97F886F737B759D499B
SHA1: DF1B440C84BA69A6D026F83821942A49D673E72D
BLAKE2sp: 19C331C9ED096FC296CA863621BEEF23BB14C89D28B5042001B37C461EB06FE1

But that's not the solution. I don't get your checksum even when I do use the right file:

Code: Select all

Name: 2019 A Sperm Odyssey.mp4
Size: 1932908295 bytes (1843 MiB)
CRC32: 146431D9
CRC64: C2F8A4E68D851DE5
SHA256: E8E94D3E91B02A256CC0083698855742076F837DEAE6F1C2239B9AC93C937707
SHA1: 667B9E5200CB65937A06D463371A51002A1237B2
BLAKE2sp: ABA18060073BCBD3342D7C2D0E36753DD409D8ACAB4362B8E7BC3FC2D301AE87

which is entirely a third set of check-sums. I dunno, you explain it.

[high_octane]

I dunno, you explain it.

Hmm... The file size differs by 53 additional bytes, so that's one reason why the checksum is different. As to why there is additional information in your file, I haven't the foggiest idea. This is very peculiar.

If you up to it, I wouldn't mind examining the differences between these two files. Technically, you're in a better position to analyze them because I don't have your version, which I would need if I were to analyze them. I understand if you don't want to deal with that, and you don't have to if you don't want to.

Lastly, here's my giant block o' sums:

Code: Select all

Name: 2019 A Sperm Odyssey.mp4
Size: 1932908242 bytes (1843 MiB)
CRC32: 871A0E7D
CRC64: C955625D0ADC6BF5
SHA256: 36BDC06FF04B77A3F2976F8C0A399617A3D1355C8BC13E3FBAADC54A044A1ABC
SHA1: 84838F5CB00F7E4DC02B81452294C3D3BB4D97DE
BLAKE2sp: 6AA045A3838C5F5078290473E28AFC7C64057D546138C923385499D42D312DBF

Here are some more, for bonus points, because why not?

Code: Select all

MD5: 60f5ae79a967e5e601bd25f800b07142
SHA512: e2cddef53a251b5a3c141989d7eaf433a7d0dd0efb9c726f9eee323797d76f56d54cd8d0bb326e1e514b2287337c8d73243e5a8cbc56dd13b0318fcbf7dcc466

[book_guy]

If you up to it, I wouldn't mind examining the differences between these two files. Technically, you're in a better position to analyze them because I don't have your version, which I would need if I were to analyze them. I understand if you don't want to deal with that, and you don't have to if you don't want to.

In fact, you have definitely piqued (although you have neither peaked or peeked) my curiosity. Extended theory below.

Spoiler: show

I won't be playing with the files personally, because the downloading bandwidth would be a problem for me. I have internet connection limitations, so I'm going to have to skip that particular obsessive-compulsive distraction. I would need to get a new "original" of the file, by downloading via one (or both) of the methods in this thread, in order to compare to the version already stored on my local hard drive. Although that would be something that I CAN do, it's something I don't WANT to do, because the file would come in at very slow speed and would interfere with everyone else's wi-fi connections here in the building where I'm sitting. Or I could try to share my idiosyncratic version with you, but, again, that would involve slow connection, this time for upload instead of download, so again it's prohibitive. Maybe if everyone decides to go out Christmas Caroling or something ... ... I'll get into it. Not right now.

One theory, by the wayside, may simply be, the encryption method with which I store my local porn. I do have plenty of porn files on the cloud shared and available to all (as you probably know, see link in .sig), but this particular cock-hero video also resides on my personal hard drive, along with a few other cock-hero files which I'm presently enjoying. I like to keep a few around for special purposes, you know, just in case the need arises . All these local porn files are on my hard drive (an SSD, not an HD, for whatever that might be worth) within an encrypted container with password-protection. This container is roughly equivalent to what the free software TrueCrypt used to create, back when in the time before TrueCrypt went AWOL. I keep the porn in an encrypted container for no special needs except the obvious and usual reasons -- this laptop is effectively my only computer, I use this laptop for tons of legitimate work and for very little personal pursuits like porn viewing, I carry this laptop around to places where other people might see what's on it, this laptop is among snooping friends and relatives and away from my oversight regularly, etc..

Therefore my local porn stays hidden. As an alternative means when the need arises , I do also view porn by streaming, from (for example) Pornhub and the many links at the many cock-hero-specific sites. But mostly I like to view porn as a local file, because (more unnecessary details) I'll be using Bluetooth headphones, but my local (cheap, antiquated) wi-fi interferes with the Bluetooth connection. So, for porn, in an encrypted container I usually keep a few files which I only ever look at by decrypting that container. In fact I'm not even "removing" the porn file from the container in order to look at it; I ran 7-Zip on it while it remained within the container.

That's my porn encryption set-up at home. All of those various encryption phenomena may be the culprit of the few extra bytes. The encryption container acts, at least for purposes of the Windows 10 file-explorer interface, as a mounted hard-drive, with a drive-letter and eject-ability and so forth. Well, that much of a new layer of interface wouldn't create extra bytes in the file. But something else about the encryption might do so before or after the connection from encrypted container to file explorer. Or perhaps 7-Zip and the encryption compete just a little bit with one another.

Just a theory. Shouldn't happen, but it might happen anyway. And, here's why it's interesting to me: if it is an artifact of encryption, then that artifact might also be an interesting hint about a potential weakness in that encryption. I don't know jack-squat about encryption, except for what you learn in a middle-school math class about Caesar's rot-13 code, but it's fun to speculate. I'd be delighted to learn more.

Additionally, I'm well aware, the extra few bytes might not be due to my encryption at all. I might have a small corruption in my version of the file, due to a glitch in transmission or storage or in encoding or decoding during the same. If you know how to figure out which is which, I'd again be delighted to learn more.

I thought I said that I wasn't going to get distracted. This thread has been officially hijacked, thanks to me. I think I'd better put this in a spoiler.

[doremi]

I downloaded the original Mega link, and I have the same SHA256 as high_octane

Code: Select all

36bdc06ff04b77a3f2976f8c0a399617a3d1355c8bc13e3fbaadc54a044a1abc

The file size is 1,932,908,242 bytes, mediainfo says 36min. 22sec. and it plays very well.

[high_octane]

Here are some additional thoughts on what you wrote, but TL;DR, I don't know the exact cause of the issue, it could possibly be from the way you encrypted it, and I doubt it is due to file transfer corruption.

Spoiler: show

I won't be playing with the files personally, because the downloading bandwidth would be a problem for me. I have internet connection limitations, so I'm going to have to skip that particular obsessive-compulsive distraction.

I understand, and that is okay.

In fact I'm not even "removing" the porn file from the container in order to look at it; I ran 7-Zip on it while it remained within the container.

Technically, when you open / double-click a file in 7-zip, it is actually extracting that file to a temporary location, which on Windows is usually %TEMP% (%USERPROFILE%\AppData\Local\Temp), and then proceeds to pass that file as an argument to whatever your default program is for that file type. Then, when you're done with that program, the file is deleted (unlinked from filesystem).

This is an aside, but if someone was super savvy, they could run Recuva, or some similar program, and potentially recover that "deleted" file. That goes for any file you delete, actually. Think of a file in a filesystem as a node. When you no longer want this file, the node is unlinked from the filesystem. However, the contents of the file itself are still intact until those exact bytes on your HDD/SSD/whatever are overwritten. Of course, if the entire drive is encrypted, then that data will look like gibberish without the correct decryption key.

Just a theory. Shouldn't happen, but it might happen anyway. And, here's why it's interesting to me: if it is an artifact of encryption, then that artifact might also be an interesting hint about a potential weakness in that encryption. I don't know jack-squat about encryption, except for what you learn in a middle-school math class about Caesar's rot-13 code, but it's fun to speculate. I'd be delighted to learn more.

I'm only really familiar with how 7-Zip encrypts files. I would hope that those additional bytes have nothing to do with the decryption key, as that would absolutely be a security risk. Ideally, the most secure method to encrypt a file would be to run the file through an excellent encryption scheme (like AES-256). and not store any information in the file or elsewhere about the decryption key. This way, any key can be used to try to decrypt the file, but if the key is incorrect, then the file will still be gibberish. In that scenario, 7-Zip would report that the CRC32 checksum (which was initially computed when the file was first added to the archive) doesn't match.

Additionally, I'm well aware, the extra few bytes might not be due to my encryption at all. I might have a small corruption in my version of the file, due to a glitch in transmission or storage or in encoding or decoding during the same. If you know how to figure out which is which, I'd again be delighted to learn more.

I doubt that this is the cause, because network transfers are typically robust. Cyclic redundancy checks (CRC) are used to ensure that the Ethernet packet's integrity is preserved:
https://en.wikipedia.org/wiki/Cyclic_redundancy_check
https://en.wikipedia.org/wiki/Ethernet_frame

If you extract the file from the archive, or decrypt it, or whatever, is the file size still larger? If the difference is at the very beginning of the file, then I'd suspect that the video would be considered invalid or unplayable by most video players. In the case that the video plays fine, I'd suspect that the extraneous data is at the end of the file.