Article

AVPS Works With Library Of Congress In Developing The Library’s National Recorded Sound Preservation Plan

Among the directives in Congressional legislation establishing the Library of Congress National Recording Preservation Board in 2000 are mandates requiring the Board to conduct a national study of the state of recorded sound preservation in the U.S., and to produce a subsequent National Record Sound Preservation Plan.  Now that the national study is complete, Chris Lacinak, founder of AudioVisual Preservation Solutions, Inc., will assist the Library of Congress by participating in a task force making recommendations for Digital Audio Preservation and Standards.  These recommendations will be incorporated into the Library of Congress National Plan for Recorded Sound Preservation.

The required recommendations will include developing a consensus on “best practice” standards in areas of audio preservation and the codification of this information for public dissemination.  Areas which will be under consideration are metadata, digital preservation, digital storage and content management, and capture of analog and born digital recordings. The group is charged with formulating ideas for developing core audio metadata schemata and the tools to create and manage metadata. Consideration will be given to scalable best practice standards that can be applied to a variety of situations, including archives with limited resources. The final plan is scheduled to be completed and released to the public mid-year 2010.

We at AVPS are pleased to assist The Library of Congress and the other preservation specialists on this project.

AVPS Participating In AMIA Conference In St. Louis Nov. 4-7, 2009

AudioVisual Preservation Solutions is pleased to be contributing to the advancement of archive community knowledge afforded by participation in three panels at the annual conference of the Association of Moving Image Archivists (AMIA) being held in St. Louis, Missouri this November.

The three sessions that we will be chairing and presenting at are as follows:

• Harnessing Collective Knowledge: Three Case Studies of New Collaborative Tools

Chris Lacinak (AVPS), Richard Wright (PrestoSpace), Mick Newnham (National Library of Australia)

A discussion and viewing of three new exciting projects – PrestoSpace’s wiki, National Library of Australia’s Mediapedia, and AudioVisual Preservation Solutions’ CEDAR – each of which provides open, collaborative, online resources that harness the expertise within the community through the use of centralized sites.

• Accessioning and Managing File-Based Born Digital Content

Chris Lacinak (AVPS), Grace Lile (WITNESS), Brian Hoffman (NYU), Dirk Van Dall (Broadway Video)

This session brings four experts and two case studies to the table to offer insights into the challenges that born digital file based video brings to your archive and offers strategies for managing it.

• Digitizing 102: Video Digitization Workflows and Challenges

David Rice (AVPS), Angelo Sacerdote (Bay Area Video Coalition), Skip Elsheimer (A/V Geeks LLC)

This session is a primer on the planning process for video digitization projects. It will examine case studies for working with damaged or ‘not-to-spec’ materials, address documentation practices for preservation workflow, and stress how to perform quality control on the process and the results.

Please join us!  We hope to see you there.
For more information about the Annual AMIA Conference:
www.amiaconference.com

Comparison Between PBCore And VMD For Technical Media Metadata

As posted to PBCore Resources

Introduction

VMD stands for Video Metadata and is a schema resulting from the Library of Congress AudioVisual Prototype Project. The documented schema lives at http://lcweb2.loc.gov/mets/Schemas/VMD.xsd and was last updated in 2003. From the annotation in the schema:

“VIDEOMD contains technical metadata that describe a digital video object. It is based upon metadata defined by LC. VIDEOMD contains 36 top-level elements.”

Carl Fleischhauer of the Library of Congress oversaw that activity and he reports that, in the end, the actual digitization was limited to audio and thus the VMD schema was never used by the project. He added that the community’s renewed interest in technical metadata means that this is an excellent time to revisit the topic and consider how best to document the relevant facts about video objects.

PBCore is a schema as well as a set of tools resulting from funding by the Corporation for Public Broadcasting. The documented schema lives at http://www.pbcore.org/PBCore/PBCoreXSD_Ver_1-2-1.xsd and was last updated in February 2009. From http://www.pbcore.org:

“The Public Broadcasting Metadata Dictionary (PBCore) is … a core set of terms and descriptors (elements) … used to create information (metadata) … that categorizes or describes …media items (sometimes called assets or resources).”

VMD and PBCore both contain specifications for technical metadata describing video. Since these “standards” were created at different times within different environments and represent two of only a few available options this blog post offers a comparison of each of their advantages.

VMD is designed to document the technical attributes of a single video object (one video file or one videotape) to be incorporated into a METS document. A METS document may contain multiple VMD instances with structural metadata describing the relationships between them. In contrast to VMD, PBCore is designed to support documentation of multiple video objects and their structure and relationships within a single record. Given these differences, meaningful comparative analysis requires identifying the appropriate level within PBCore to compare with VMD. VMD is roughly the semantic equivalent to the PBCore’s instantiation element and sub-elements which will serve here as the level of comparison.

The objective of performing this analysis is two-fold. First, to highlight some differences that may be helpful to those considering using either one of these schemas, and second, to identify specific strengths and weaknesses, some of which may prove to be valuable points of consideration for future alteration of both standards.

So let’s begin!

Flexibility vs. Control: Man vs. Machine

The design of the PBCore XML schema definition allows for almost all of the values to be expressed as flexible text strings (exceptions to this are ‘language’ and ‘essenceTrackLanguage’ which must be expressed as exactly three letters between ‘a’ and ‘z’). This allows for a field like ‘formatDataRate’ to use “Video 25 megabits/sec”, “Video 3.6 megabytes/sec”, “25 mb/s”, “3.6 MB/s” or “26085067 bytes/second”. Although each of these PBCore values are human-readable and easily understandable, the flexibility allowed in expressing technical data makes it difficult to sort, filter, or evaluate PBCore records from different systems. For instance, if a PBCore record is evaluated to determine if an instantiation is compliant with a broadcast server’s specification, the evaluation process is challenged if one PBCore system says “44.1 kHz” and another says “44100” or one system says “4 Mb/s” while another says “524288”. The equivalent fields in VMD are used solely for the value while the unit of measurement is a fixed aspect of the value’s definition. Phrases that would be mixed into PBCore technical values like ‘ fps’ and ‘ bytes/second’ are not necessary (and not valid) in VMD.

As mentioned, VMD’s XML schema approaches technical data with more constraint. The schema constrains allowable values through validation rules to various data types like integers, text strings, or schema defined data types. The VMD equivalent of PBCore’s ‘formatDataRate’, ‘date_rate’, will not validate unless it is expressed solely as an integer. This restriction enables better interchange and forces the user to a specific manner of expressing data rates rather than stating the value in a unit of measurement within the field itself (PBCore-style).

In general VMD enables greater interoperability because of the constraints on allowable values, but in a few cases the constraints inhibit the entry of valid information. For instance ‘frame_rate’ must be an integer, so frame_rate=”30″ is valid, but frame_rate=”29.97″ is not valid. In this case, PBCore may more accurately represent technical data that requires decimal values, such as “29.97”. Within some organizations VMD has been extended to allow decimal values in place of integers.

Attributes

Both PBCore and VMD utilize XML attributes in order to augment XML data. VMD uses an ID attribute to allow unique identification of XML elements within the VMD document. Thus individual XML elements that may occur multiple times within a VMD record such as ‘compression’, ‘checksum’, ‘material’, and ‘timecode’ may be referred to elsewhere via the ID attribute value. The ID attribute serves a role similar to keys within a database. VMD also uses attributes for identification of an item as analog or digital (similar to PBCore’s use of formatDigital or formatPhysical) and for describing the dimensions of a piece of media.

PBCore 1.2.1 contains one attribute called “version”, an optional attribute to refer to the specific PBCore schema utilized. This attribute may occur within elements of type “pbcore.string.type.base” and “pbcore.threeletterstring.type.base (about half of the PBCore elements).

The use of attributes within these standards accomplishes different goals. PBCore’s version attribute potentially helps in the upgrade process of PBCore records to newer versions of PBCore since the “version” attribute can clarify which release of PBCore applies to the document. Since both VMD and PBCore have moved elements around and changed their definitions with various releases this attribute provide significant value in helping conform records from multiple sources to the current PBCore release.

The use of ID attributes in VMD allows the various elements to be related within a metadata framework. As PBCore user-feedback often points out the need for internal linking inside a PBCore document such as associating a rightsSummary with a specific instantiation or stating that this audienceLevel corresponds to that instantiation but not this one, the application of internal identifiers, such as VMD utilizes, may be worth considering in further PBCore development.

Checksums

Checksums are pertinent to the management of a digital archive and VMD provides a ‘checksum’ element that may contain ‘checksum_datetime’, ‘checksum_type’, and ‘checksum_value’. This allows VMD to document multiple checksum algorithms as applied to a digital object over time.

While PBCore’s schema and document do not directly address checksums, it is feasible that checksum data could be stored in the ‘formatIdentifier’ field (where the checksum algorithm and date is the ‘formatIdentifierSource’) or perhaps as an ‘annotation’. Since the transaction of metadata and content is a key use of PBCore and checksums validate the successful transaction, it is recommended that PBCore users determine or adopt a best practices strategy for handling checksums or that checksum management becomes a consideration of further PBCore development.

EssenceTracks and Compression

PBCore instantiation records contain ‘essenceTrack’ elements to describe the various tracks of a media object, such as video, audio, subtitle, timecode, captioning and more. In contrast VMD records do not document the individual tracks but, more specifically, the types of compression used in the file. Although VMD allows for preservation-orientated values such as ‘codec_creator_app’ and ‘codec_quality’, PBCore’s essenceTrack is more extensive with regard to technical and structural information.

formatGenerations and use

The VMD value for ‘use’ must be either ‘Master’, ‘Service’, ‘Service_High’, ‘Service_Low’, or ‘Preview’. Other values for ‘use’ would invalidate the record. For organizations that do not use this terminology this could be an awkward fit and cause semantic confusion. In contrast, PBCore’s ‘formatGenerations’ value may be any text string and provides an extensive list of suggested values at http://www.pbcore.org/PBCore/picklists/picklist_formatGenerations.html.

Summary

VMD’s XSD is much more prescriptive than PBCore for which values may be used to describe various technical aspects of video. Attractive qualities of VMD include:

•          Fields for documenting checksums, their datetime stamps and types.

•          Fields for documenting the encoding environment, compression quality, and tools that manage encoding/transcoding.

•          Unique IDs for XML elements, enabling some linking where elements are repeatable.

•          More extensive validation enables greater interoperability between systems.

In comparison to VMD, attractive qualities of PBCore include:

•          A metadata structure that more closely mimics audiovisual wrappers (by the instantiation, essenceTrack and annotation elements)

•          Greater degree of flexibility along with a greater capacity for data

•          Extensive recommendations for controlled vocabularies

•          A support system around the schema to provide information to the user on best practices, suggested vocabularies, tools to implement the schema

•          And last but not least – PBCoreresources.org !

Eggs in One Basket?

It’s important as a community to figure out whether there is more value in having two standards to express technical video metadata or one. Maintaining two standards raises many issues. For instance, two issues which affect the compatibility of the two standards are:

•          the scope of technical metadata

•          structural relationship of the metadata’s subjects (asset, instantiation, etc)

However, both VMD and PBCore have advantages over the other in the scope of technical metadata covered by the system. In some environments increased documentation on tracks and annotations may be preferable whereas details on checksums and codec creation environments may be more relevant to another. Either of these standards could be extended to accommodate the advantages of the other (potentially PBCore could already handle VMD’s additions with the definition of best practices for their implementation).

Currently the standards are not interchangeable due to structural reasons and variances in the scope of technical metadata. PBCore is orientated to a fixed relationship between descriptive and technical metadata (a PBCore document must have at least one instantiation and an instantiation must have an asset) whereas VMD is technical only. A strategy that could harmonize these two standards could include defining the PBCore instantiation element itself as its own “mini-standard”. With this approach either VMD or PBCore could accommodate the advantages of the other standard while offering similar implementation strategies.

My hope is that this post offers some insights and generates some discussion in response to these thoughts and questions. In a best case scenario, this may result in some sort of community consensus on a path forward. In the absence of this ideal, I hope that this post offers some thoughts for consideration that will help you, the reader, make an informed decision on selecting a path that best aligns with the goals and needs of your organization.

Dave Rice, AudioVisual Preservation Solutions

thanks to Carl Fleischhauer and Joe Pawletko

Instantiations, Components, And Essence Tracks

As posted to PBCore Resources

PBCore instantiation records work well for documenting renditions of an asset that are composed of a single tape or file, but when an instantiation requires multiple tapes, reels or files what should the protocol be? How can PBCore be used to efficiently document a rendition of an asset that is composed of multiple objects, each with its own set of technical metadata? Disclaimer, this post is based on my own personal experience in using PBCore 1.2.1 and resulting conclusions.

Within a PBCore asset record every element may be applied multiple times (one asset may have as many titles, contributors, and instantiations as one desires); however from the perspective of the instantiation (which is a single rendition of an asset) much of the descriptive information may only occur once. For instance, an instantiation may only have one formatDigital (i.e. one mime_type), one formatGenerations, one formatFileSize. The PBCore instantiation element appears to be designed to both document a single item or a single file and to document “all the details on how the asset is actualized” (quote from the PBCore 1.2.1 XSD). However, in some cases, in order to document how an instantiation actualizes the asset, multiple files or multiple items are necessary. Here are three situational examples:

– an asset describing a musical album may have an instantiation that is one CD, then the digitized version of that CD comprises 10 digital files each representing a track. The 10 digital items together represent the same asset as the single-item CD,

– an asset describing a film exists in a collection as two instantiations: a three-reel 35mm film print and a single Digibeta (this is similar to the example that Mary Miller describes at http://www.pbcoreresources.org/article/dealing_with_multi_part_instantiations/),

– an asset documenting a television episode contains two instantiations: one being a single Digibeta tape and another as two elementary stream files (an .m2v video stream and an .wav audio stream).

All three of these examples refer to audiovisual material that changes in number of components needed to represent an asset over the reformatting process. In some types of reformatting the number goes from more to less (like example 2, the film transfer) and in some cases from less to more (link example 1, the digitization of a CD).

If PBCore instantiations are understood to only represent single-item instantiations then the individual digitized tracks of a CD or the individual reels of a film print would need to be documented in their own asset records, where one asset represents the CD and then 10 other assets represent the individual digitized tracks. This is obviously less efficient than treating the set of digitized tracks as one instantiation and the CD as another instantiation of the same asset. Another option could be to zip or tar the 10 tracks into one file, but this requirement for effective PBCore description has its own disadvantages. Alternatively a directory that contains the 10 file-based tracks could be defined by the instantiation.

Best practices for documenting multi-object instantiations are not clear. With the m2v and wav elementary streams, the two files need to work together to represent the asset, but they have their own unique values for ‘formatDigital’, ‘formatFileSize’, ‘formatDataRate’ and possibly their own ‘formatLocation’. All of these values may only occur once per instantiation. For the m2v and wav elementary streams to be defined as a single instantiation some options are:

– the two files could be moved into a directory or folder, which would serve the role of an audiovisual wrapper. In this case the formatDigital would be ‘application/x-not-regular-file’ (referring to the directory) the formatFileSize could be the directory size, etc.

– or the data from the individual files could be shoehorned into the instantiation fields meant for individual files, thus formatDigital would be “video/mpeg audio/x-wav” and formatFileSize could be the sum of the two file sizes.

– or the m2v and wav files could be either zipped or tarred into a single file or multiplexed into an audiovisual wrapper, so that the collection is then represented by a single file (the analog equivalent would be splicing together film reels in order that the metadata more cleanly fits into an instantiation record).

None of these options are ideal for describing a complex object, since potentially the levels of quality of resulting technical documentation become less precise, the implementation of instantiation becomes less standardized, or the metadata process potentially burdens collection management. This is the same sort of challenge that occurred in pre-1.2 versions of PBCore where discrete track-level metadata values had to be concatenated and labeled into single fields like formatDataRate = “Total 1930 kilobits/sec; Video 1700 kilobits/sec; Audio 230 kilobits/sec”. This procedure was documented by pbcore.org at http://www.pbcore.org/PBCore/formatDataRate.html that “the pbcoreInstantiation container should not be repeated in order to express a video data rate and an associated audio data rate. The two combined are part of a single instantiation for an asset”.

I have two suggestions regarding this potential challenge. The first would be documenting best practices the use PBCore 1.2.1 as is to document these complex objects in a way that fits the various examples above. The second suggestion would involve a modification to PBCore which would be to integrate an additional element in between instantiation and essenceTrack, perhaps called ‘component’. Typically PBCore would document single-component instantiations; however in cases where a single instantiation is made up of multiple tapes, reels or files, the instantiation would have as many component records each with its own technical metadata.

In this arrangement some of the values currently attached to instantiation would move to the component level. Whereas PBCore 1.2.1 is

instantiation { {formatIdentifier, formatIdentifierSource } dateCreated, dateIssued, formatPhysical, formatDigital, formatLocation, formatMediaType, formatGenerations, formatFileSize, formatTimeStart, formatDurations, formatColors, formatTracks, formatChannelConfiguration, language, alternativeModes {essenceTrack see below } {dateAvailableStart, dateAvailableEnd } { annotation }

essenceTrack {essenceTrackType, essenceTrackIdentifier, essenceTrackIdentifierSource, essenceTrackStandard, essenceTrackEncoding, essenceTrackDataRate, essenceTrackTimeStart, essenceTrackDuration, essenceTrackBitDepth, essenceTrackSamplingRate, essenceTrackFrameSize, essenceTrackAspectRatio, essenceTrackFrameRate, essenceTrackLanguage, essenceTrackAnnotation }

the incorporation of a component level of data could look like

instantiation { assemblyMode, formatMediaType, formatGenerations, formatFileSize, formatColors,, formatChannelConfiguration, language, alternativeModes, {dateAvailableStart, dateAvailableEnd } { annotation }

component { {componentIdentifier, componentIdentifierSource } dateCreated, dateIssued, componentPhysical, componentDigital, componentLocation, componentTimeStart, componentDuration, componentTracks, {essenceTrack see below } }

essenceTrack {essenceTrackType, essenceTrackIdentifier, essenceTrackIdentifierSource, essenceTrackStandard, essenceTrackEncoding, essenceTrackDataRate, essenceTrackTimeStart, essenceTrackDuration, essenceTrackBitDepth, essenceTrackSamplingRate, essenceTrackFrameSize, essenceTrackAspectRatio, essenceTrackFrameRate, essenceTrackLanguage, essenceTrackAnnotation }

In this draft I added a field called ‘assemblyMode’. Something like assemblyMode would be needed to document how the components are related to each other. In the case of the digitized CD, the components would be assembled through concatenation and played back-to-back, so assemblyMode could equal “concatenation”. With the m2v and wav elementary streams the assemblyMode would be “multiplexion” since the component needs to be multiplexed for playback. In the case of “concatenation” the total duration of the instantiation would equal the total durations of the components whereas if the assemblyMode is “multiplexion” then the instantiation’s duration is roughly equal to the duration of the component, so the value is relevant to how other pieces of metadata are determined.

Since the instantiation should contain “all the details on how the asset is actualized” (as stated by the PBCore 1.2.1 XSD), adding an addition element level to accommodate multi-tape or multi-objects would help this goal be achieved with cleaner and more descriptive data. I’m interested to hear if this is an issue another other PBCore users are thinking about and if there are any easier solutions that I’m missing.

David Rice

AudioVisual Preservation Solutions

AVPS Participating In “Preservation Oriented Production Workflows” Session At The AMIA Annual Conference On November 13, 2008

Chris Lacinak of AudioVisual Preservation Solution will be speaking at a session at the Association of Moving Image Archivists (AMIA) annual meeting in Savannah on the topic of “Preservation Oriented Production Workflows”. He will be chairing a panel joined by Brian Hoffman and Kara Van Malssen of NYU, and Jonathan Marmor of WNET.

The summary program description is as follows:

“Traditional workflow models pose great challenges to preserving and managing content over the long term. After years of grappling with them, these challenges have become all too evident to the AMIA community. A new model of production has begun to evolve from this awareness, and with some surprising consequences.”

We welcome all AMIA Conference attendees to join us as we share in our experiences while defining a new model of preservation oriented production workflows that will undoubtedly impact the future of archives.

The website for the 2008 Annual AMIA conference is here:
http://www.amiaconference.com/index.html

AVPS Participating In The 125th Annual Audio Engineering Society (AES) Convention In San Francisco October 2-5, 2008

Chris Lacinak of AudioVisual Preservation Solutions, as well as a long term participating member of AES, will make several contributions to this year’s convention. He will be presenting at a tutorial titled “Audio Preservation at the National Audio-Visual Conservation Center (NAVCC)”, and will introduce Brad McCoy, who is a Senior Sound Engineer at The National Audio-Visual Conservation Center, Culpeper, Va.

“This tutorial will discuss audio preservation at the Library of Congress’ National Audio-Visual Conservation Center (NAVCC) that was recently completed in Culpeper, VA. It will also give an overview of the NAVCC, a state-of-the-art facility for storing and preserving recorded sound, video, and film materials.” The tutorial will take place on October 4, 11:00 am — 12:00 pm

In addition, Chris will be co-chairing the standards committee workgroup on audio metadata and will be working towards the standardization of the emerging audio metadata (SC 03-06)

Chris hopes to have an active and productive conference and looks forward to sharing what he learns from his colleagues.
The link to the 2008 AES Conference Website is here:
http://www.aes.org/events/125/

The Archivists Round Table Of Metropolitan New York (NYART) Is Hosting A Workshop On “Digital Asset Management And Institutional Repositories” On November 10th, 2008

Chris Lacinak, founder of AVPS and Education Coordinator at NYART is pleased to announce an upcoming workshop titled “Digital Asset Management and Institutional Repositories: Case Studies Addressing the Development and Implementation of Systems”, which will be held on November 10th at The NYU Kimmel Center in New York City.

This workshop consists of three presentations from a group of five experts. These presentations will present case studies of projects in which they have been involved. The projects span all relevant content and media types including documents, still images, moving image and sound. The presenters will share their valuable experiences, focusing on covering concerns and questions that many NYART members are, or will soon be asking as they embark on their own projects.

The Speakers will be Leala Abbot – Digital Asset Librarian, Enfatico; Einar Brendalen – Image Systems Analyst, Metropolitan Museum of Art; Jonathan Marmor – Manager of IT and Broadband Operations, Thirteen/WNET New York; David Rice – Digital Media Archivist, Thirteen/WNET New York; and Sunny Yoon – Digital Resources Coordinator, The City University of New York, Office of Library Services.

Development and implementation of these systems is a topic that has been, or will soon be tackled for the first time in many organizations. For those organizations already beyond this initial milestone, the challenge and experience serve as practice while they look forward to repeating the process many more times to come.

AVPS Working In Ghana To Help Save The Country’s Moving Image And Sound Heritiage

Chris Lacinak of AVPS traveled to Ghana for three weeks early this summer as part of the Audiovisual Preservation Exchange (APEX) team. APEX is a recently established effort stemming from NYU’s Moving Image Archiving and Preservation (MIAP) Program . The team’s activities were multi–faceted and focused on Ghana’s moving image and sound heritage.

These activities included visiting and interfacing with partner organizations, vendors and technicians to determine current audiovisual preservation capabilities, and to obtain the functional resources needed for local involvement in preservation efforts.

The APEX team met with archives and libraries of cultural institutions located in Accra and Cape Coast, Ghana. These institutions hold rich collections of sound and moving images documenting Ghana’s history. These meetings focused on issues of archiving and preservation while exploring ideas for possible collaborative projects with NYU and MIAP in Ghana.

A considerable amount of Chris Lacinak’s time was spent in supporting Seth Paris, a Fulbright Scholar, who is in Ghana working on preserving the recordings of Ghanaian music legend Kofi Ghanaba (Guy Warren). Chris Lacinak performed an assessment of the audio collection and installed an audio digitization lab at the NYU in Ghana Academic Center. Documentation of preservation workflows, metadata specifications and training materials were also developed in support of the current and ongoing efforts of the audio lab. The lab is capable of preserving content housed on open reel audiotape, audiocassette and analog discs.

The Ghanaba collection serves as a pilot project for the audio digitization lab. The goal is to establish ongoing capability for use as a resource in the preservation of Ghana’s audio heritage.

Digital Asset Management With Free And Open Tools

David Rice and Mike Castleman represented Democracy Now! at the 2008 AMIA Digital Asset Symposium presenting on the integration of open source technology and Free Software in efforts to record, disseminate, and archive moving image media.

The presentation included references to:

• Tools for Recording: dvgrab, cron, vidi
• Tools for Transcoding and Wrapping: ffmpeg, mplayer, MP4Box, ffmpegX, x246 for Quicktime
• Tools for Online Media Accessibility: The Internet Archive, blip.tv, Miro
• Tools for Migrating AudioVisual Data from Tape-Based Digital Media: DATXtract and Live Capture Plus
• Tools for Backup and LTO Management: Bacula
• Metadata Extraction Tools: MediaInfo, getid3, qt_tools
• Metadata Standard: PBCore
• DAS (PDF)

AVPS Moves Office Location To Flatiron/Chelsea, Manhattan

AudioVisual Preservation Solutions has moved its operations to the historic Masonic building on the corner of 6th Avenue and 23rd Street, Manhattan. This move brings us closer to a greater number of our New York clients, and affords us the opportunity to conduct hands-on audiovisual preservation workshops for our clients in an easy to reach location.

While we will miss Williamsburg, Brooklyn, we are pleased to be better situated to serve our clients in the historic Masonic building.

Our new Address is:

AudioVisual Preservation Solutions
71 West 23rd Street
Suite 504
New York, NY 10010

« Previous Page — Next Page »