![]() |
2257 record keeping. Solution or am I an idiot?
This wouldn't help with old content but anyhow...
Say content providers put a tiny, barely noticable, stock number at the bottom corner of every picture in a set. That combined with a premade records page including the stock numbers for all models in that set would make for very easy management. Or am I a dumbass? |
porn bar codes?
|
Or naming the file names and not allowing them to be changed.
|
Quote:
Good idea, but the problem is implementing such a system... i know it's very easy to run a batch job to watermark images, but most content producers don't have the time, or some may just not know how to do it. Being able to identify an image, whether through watermark, jpeg header / EXIF header.. would definitely go a long way to helping to identify a file (tho some resizing programs remove this kind of info). Using stenography (invisible watermarking) is a possiblity, but the last time a company rolled through, they were wanting to charge $1 per image. The problem of how to figure out which content producer an image belongs to is exactly what i am addressing with 2257lookup.com Going forward, content producers can do proactive things as you have suggested.. will they do it? Some don't even have proper 2257 documentation for their own images... -brandon |
Quote:
|
Quote:
|
Quote:
that's technically impossible to do. A webmaster copies images from a zip file or from a CD to their hard drive, they run a thumbnail/resizing tool that also batch renames the files.... some wipe out header/exif info. -brandon |
Quote:
That idea won't fly well with webmasters, some have their own naming conventions of what they want to call the file. Should a content producer impose this restriction, webmasters will just get their content from somewhere else. If a webmaster renames the file, it's their 2257 record keeping problem, not the content producers. -brandon |
Part of running any business is keeping track of your own shit. There is nothing difficult about organizing your content in such a manner that you know who you got it from, what you renamed it to, and where you used it.
The biggest difficulty with the new 2257 changes will be going back and recouping info that you didn't keep track of because you didn't think you had to. Going forward, since you now know you need t keep track of the info should be rather painless. If you deal with small amounts of conent, make up a sreadsheet or a simple notebook and keep notes of who, what, where and when. Also organize the conent on your disk in such a manner that you can track back. If you deal in large content quantities then you are probably using a more automated approach. If you are using your own custom programs then add the tracking into the code. If you are using purchased software that does not include any kind of databasing method then chuck it and find a program that does create a track for you. It is not up to the content provider to track this stuff for you. It is up to you to run your business properly, noone else. |
Quote:
However, if a content provider sold that content with some form of tracking in place that content would only have to be worked on once. I would imagine they would get a boost in sales if not everyone was doing it. With the price of outsourced workers this wouldn't cost them much and it would allow anyone to start with a compliant site. Just my opinion on the matter but I bet someone does something like this in the near future and I would also wager they make way more additional money than the few bucks it would cost them to have somone run through the content to make it managable. |
Quote:
shall be organized alphabetically, or numerically where appropriate, by the legal name of the performer (by last or family name, then first or given name), and shall be indexed or cross-referenced to each alias or other name used and to each title or identifying number of the book, magazine, film, videotape, computer-generated image, digital image, picture, URL, or other matter." These indexing/cross-referencing requirements pretty much guarantee that, even if your idea were flawless, it would not make for "very easy management". No idea will, unless it were to be universally adopted. Realistically that isn't going to happen. I guess it is inevitable that people will offer 2257 services and I'm sure they will find customers. I wish it were otherwise, because the prospect of blending the output from several services together with a mix of "traditional" records, is more daunting than the already horrible task of dealing with traditional records alone. |
Quote:
|
Your talking about a tracking system that at my end involves over 200 content producers and over two million images. If I had a staff of 100 people I wouldn't be able to get that done in sixty days.
Website owners already have an online database - It's called a member's area. Keep records locally of a model's legal name, birthdate, name of the producer, and stage name. Then use your member's area as a database - The model's stage name is "Jordan" - Click on the link to Jordan's pictures in the member's area which brings you to a page listing all of "Jordan's" pictures. Right? |
Hmmmmm.....
It might be possible to make a system where you run your pictures through a "mark" batch, where it save info on each image on the server in a database and then after that it would be possible for the webmaster to upload scanned copy of whatever for each set / folder. Then make a review part that have a review method kinda like a TGP review script where you associate the correct ID's with the correct sets / folders. And then we could just hand out logins to the server to the government upon request. I could do it for a small fee of $15,000 for a multi server license :thumbsup Seriously I will look into it and I might be able to come up with a solution. A HUGE central server with a monthly rent from the users could be possible |
Quote:
|
It would be something and it could possibly work but it would just be implementing it that would be hard.
|
All times are GMT -7. The time now is 05:53 AM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123