Thanks for all the replies, it sure helps me evaluate how realistic is my
inquiry. I will think about it and choose a compromise solution.

Thanks to all!

Laurent Bellemare,
Étudiant en musicologie


Le lun. 7 oct. 2019 à 16:44, Eli Bildirici <
[log in to unmask]> a écrit :

> Hi Corey-
> ...if there is data compression at all on a server you are uploading to,
> then it is probably lz4 or something, at the filesystem level. This is both
> free from a performance perspective and lossless from a data-integrity
> perspective, provided your host is using an enterprise-grade filesystem
> like ZFS. Which it's practically guaranteed that they are, in 2019. If you
> want to be extra paranoid, you can, before uploading, generated parity
> files using something like QuickPar or similar, and then back those up, but
> this is not necessary, at least not for the purpose of making sure your
> providers aren't messing with your files somehow, because this isn't
> happening. Think about it. If it were, there would be no point of e.g.
> uploading a hash along with a file, if it turns out the file you've
> uploaded is modified upon upload thanks to the compression you seem to be
> afraid of, then that hash'd fail every time. IRL this doesn't happen. Now,
> if you're using a service that explicitly uses lossy compression (e.g. if
> you give it wav/flac, it converts to mp3/mp4/ogg/opus; if you give it a
> tiff/png, it converts to jpg/heic, etc)...well it's told you that in
> advance, and anyway such a service would not be appropriate for this use
> case. But it seemed like you were making a broader claim than that here,
> particularly in your last email.
> Laurent--
> I don't think what you're looking for--basically,, but with
> access control--exists. And if it did, no way it would be free, unless
> ad-supported, which is kind of icky for your use case. You could try using
> a web portal that'll have all your metadata etc that linked to files hosted
> on other service, but this is, obviously, inelegant, and not all that
> different from what you're doing--just more pleasant to navigate than a
> directory at Mega. It also wouldn't really solve your access control
> issue--you could restrict who can see the links to the copyrighted material
> like this, but the links themselves wouldn't be temporary, so you That
> said, it'd probably be cheaper than paying out your nose to host all your
> files, though. Sorry nothing better is occurring to me right now, but
> looking fwd to other responses--hope you find what you're looking for.
> Eli B
> October 7, 2019 12:56 AM, "Corey Bailey" <[log in to unmask] (mailto:
> [log in to unmask]<[log in to unmask]>)>
> wrote:
>         Hi Richard, Yes, that was a sweeping statement, meant to raise the
> awareness of those who use the internet (Cloud) which, includes the vast
> majority of us and our offspring. The fact is that most, if not all, who
> rent server space use some kind of data compression to save space (and $).
> Most will not tell what they use. You can buy data compression/encryption
> software that will return bit-for-bit. Some are OK with the concept, some
> are not. One possibility is to use a code (There are many variants) in the
> metadata of the files you plan to store to insure that you get the same
> files back. Here is another sweeping statement: I try and avoid those that
> do data tracking. ALL OF THEM (can you say VPN?) and, I plan to disengage
> completely from all social media by the first of the year because of data
> tracking regardless of your settings (preferences). I do however, use
> Dropbox. At least, temporarily. I plan to dump them as soon as my paid
> service runs out due to slow upload speeds. I have a 70Mbps service but
> Dropbox is very slow to upload, about a third, or less, of what I have
> available (Can you say /throttling/?). I don't use Backblaze because I
> clone my boot drives instead of doing backups. Apologies to the list for
> being way off topic. Da Ole' curmudgeon, Corey Corey Bailey Audio
> Engineering On 10/6/2019 11:24 AM, Richard L. Hess
> wrote: Hi, Corey,
> That is a sweeping statement that I think needs clarification.
> My take on this statement is:
> Google Photos: True if you select the unlimited option, not true if > you
> pay for the storage.
> Dropbox: The only compression that they use is perhaps totally >
> transparent data compression on the server side (I have no evidence of >
> that) but they deliver files back to you as you sent them. While >
> originally running on Amazon Web Services, they have migrated to their >
> own multi-location cloud.
> Backblaze: Although not a cloud service per se, but rather a backup >
> service, I believe they do de-dupe your files and only save one copy, > but
> otherwise they give you back what you sent in (again, they may use > sever
> side lossless data compression).
> Amazon Web Services/Glacier/etc: These services give you back what you >
> put in.
> There are many others, but these are some I've looked into over the > past
> few years. At the moment, I use the first three and had long had > a
> thought about using AWS/Glacier.
> I don't know a good solution that meets the OPs requirements except >
> perhaps splitting items between a service which allows passwords (paid >
> service) and the Internet Archive for the free-access stuff.
> Cheers,
> Richard
> On 2019-10-06 1:44 p.m., Corey Bailey wrote:Hi Laurent,
> Know that almost all on line storage uses some kind of data >>
> compression. Besides your password requirement, you need to consider >>
> which type of data compression will best suit the needs of your >> material.
> Best,
> Corey
> Corey Bailey Audio Engineering