TLDR? Have a glance at README.txt to catch up with Scald in 5 minutes.
Scald (SCALD is Content, Attribution, Licensing, and Distribution) is a different take on how to handle media (audio, video, image or otherwise) in Drupal.
The problem that sparked the development of Scald is obvious all over the web. When I (the end-user) want to post something online I first must figure out what type of thing I'm posting. If I am writing something for my personal blog about my vacation last weekend, I'll open up Blogger and start writing. But then I realize that I have a video which I want to include in my post. So I open up YouTube, check to see if the video format that I have my video in is compatible with YouTube, upload my video, copy the embed code, paste it into Blogger and then test my post to see if the video actually embedded properly. THEN, I can get back to writing my post -- only to realize that the photos I took on the trip would be good to include too, so I open up Flickr...
As the narrative above highlights, the web currently has "silos" of media which are exposed to the end-user. I shouldn't have to care that YouTube is where videos live. Or which codecs YouTube supports. I should be able to just upload my video directly in Blogger, pay no attention to where its being stored and put it in my post. Similarly, if the video is already online, I shouldn't have to figure out if the embed code from Vimeo is different than the one on YouTube. I should just be able to select my video and put it in my blog post -- ideally from right within Blogger. And this should apply to audio, images, and video -- all regardless of the source (my hard drive or someone else's website).
To make things worse, we have not even begun to consider the licensing implications, we're just discussing a format usability problem. The average user has no concept of the intracacies of "fair use" or "attribution share-alike". Despite all the efforts by the Creative Commons folks, these are concepts which are very difficult for those who don't deal with such issues daily to understand. What I want to know is "how do I get that video in my blog post?". There should be a mechanism which distills the licensing issues down to "can I use it or not?" Even better, the content which I am not allowed to use in that way shouldn't even be exposed in the interface. The related problem of "how do I let other people use my stuff without giving it away" is something that casual content creators may or may not consider.
Scald strives to be "content-type agnostic". This creates some difficulties in language when discussing Scald because one cannot say "media" or "multimedia" because Scald can be extended to handle anything -- audio, video, images, plain text, files, code, even interactive elements like an embedded Flash game. "Content" is used as a generic term to describe any and all of these things and ultimately represents what it is that the end user wants to publish online (which is usually some combination of the different elements listed above).
Scald is content-type agnostic in two different ways. First, only the "colloquial" type (audio, video, code, etc.) is presented to the user while the format type (PNG, JPEG, AVI, MPEG) is irrelevent. Everything is distilled using the Scald Unified Type system which allows a developer to arbitrarily define a type and then further define what belongs to that type. Since the primary use case for Scald is in (multi)media handling, the "standard" Scald Unified Types are audio, video, and image.
The second way that Scald is content-type agnostic is that regardless of the Unified Type of a particular piece of content, it is handled in an identical fashion. Including a video in a blog post is identical to including an image or an audio clip. Embedding a video is no different than embedding an image. They all have a title, an author, a thumbnail representation, and so on.
Another key element to Scald is that each individual image, video, or audio clip is a single entity known as a Scald Atom. The word "atom" is intentionally chosen to imply that it cannot be further deconstructed. Within Scald, whenever one references a particular image, the author, date of creation, title, description, licensing restrictions and so forth are explicitly included and available. In order to fully and effectively exploit the classification of content, two images should not be combined into a single Scald Atom.
In summary, a Scald Atom is a singular piece of content (often media) which has a standard set of metadata associated with it, including its Scald Unified Type which is used to classify the Atom within Scald.
Additionally, Scald - in tandem with the DnD module - provides a novel and natural way for users to compose complex posts. Scald provides a standardized mechanism for manipulating various types of media. Users can specify licensing on their uploaded media, re-use it for themselves, offer it to others for re-use and track all of those interactions without interfering with any other Drupal functionality.
Given that one of the primary goals of Scald is easy re-use of content, the proper tracking and acknowledgement of the original author of an Atom becomes very important. As mentioned above, when working within Scald either as a developer or as an end-user, it is impossible to separate the author from a Scald Atom. This means that upon display of an Atom if attribution is one of the terms of the license, the original author's name will be displayed in addition to the actual content of the Atom.
Another important benefit of careful tracking of authorship throughout Scald is that despite an individual Atom used both on and off the site, the original author can keep track of where his or her work has gone. When operating within a single site using Scald it is obvious to see how this can be handled, but allowing for such tracking off-site is a different issue entirely. This is covered in more detail in the "Distribution" section, but the key point is to make the interface for including a Scald Atom in an external site so simple and convenient that there is little incentive for an end-user to go to the trouble of extracting the original content from its Atomic context of authorship.
The other expected benefit of careful management of authorship is the ability for end-users to find other content by favorite content creators. When looking at a blog post with a nice picture of a cat, one can easily determine whether the author of the blog post took that picture and if not, where to find more photos from the same original photographer -- information which is often lost if the blog post author does not bother to attribute the photo (or cannot because the information was lacking at the original source).
An obvious issue when considering attribution is the posting of content by users who are not the original author. Scald makes provision for such an instance by allowing for authors who are not users of the site where Scald is in use and by encouraging the inclusion of such an option in the interface.
The obvious complement to the attribution components discussd above is the Licensing component of Scald. Scald makes use of a fine-grained permissions model to allow for the implementation of a variety of different licenses. With a particular eye toward the standard suite of Creative Commons Licenses, Scald defines various actions that can be taken regarding a given Atom. Combining actions such as editing, downloading the original source content, re-using content with or without attribution, and granting additional re-use by others, Scald allows for the definition of application-specific licenses.
Revocation of a particular license or permission is relatively painless through Scald. Since all re-use is registered centrally within Scald, the Atom in question can be very simply "blanked out" and an appropriate notice can take its place. This is clearly and important element to include -- in tandem with the attribution of content to non-users -- in today's media climate. Any site which relies on user-submitted content needs to consider what happens when a copyright claim is leveled against them and having the capability to revoke inclusion permissions built in from the start is an excellent defense.
The distribution piece refers to both local distribution as well as remote distribution. Locally, the most important element of Scald is the idea of Display Contexts. In an effort to enable good re-use of content, a given Scald Atom can be displayed in an arbitrary number of Display Contexts which control things like the space consumed on the page, the amount of non-mandatory metadata that is included and so on. The mechanism for determining the Display Context for a given instance of displaying an Atom is multi-tiered. Each Unified Type has a fallback Display Context which ensures that a bare minimum of essential elements are displayed for any given Atom of that Type.
Distribution beyond the confines of a given site where Scald is resident is handled through a variety of means including both an end-user-focused "embed code" mechanism as well as API endpoints enabling external developers to interact with content within Scald while gaining all the benefits and abiding by all of the restrictions that content within Scald enjoys.
Author tracking, licensing restrictions, "similar content", and easy re-use are all benefits to making use of Scald's distribution both internally and externally.
While 6.x versions are actually used in production in many sites, new development focuses on 7.x branch. If you want to test, or to use Scald in your new website, 7.x-1.x is the obvious choice. If you want to start a new Drupal 6 site, you can use the 6.x version, but please don't expect for a stable release.
Those pages are mainly for 7.x version.