search

mipops / dvrescue

Archivist-made software that supports data migration from DV tapes into digital files suitable for long-term preservation. Snapshot daily builds are at https://mediaarea.net/download/snapshots/binary/dvrescue/.
BSD 3-Clause "New" or "Revised" License
90 stars 20 forks source link

recognize non-standard playback speed #328

Closed dericed closed 2 years ago

dericed commented 3 years ago

BAVC1010855_DV000161_take01-002_rew.dv.zip

This sample shows a DV tape made by playing one DV tape and recording to another (with a firewire connection between two decks). This shows the recorded DV tape. The first few frames show the recorded frames when the playing tape is in pause mode, then the subsequent frames show the recording tape recording the playback tape as it rewinds. As it rewinds the recording frames include DIF blocks from a variety of playback frames and the recording timestamps and timecode descend. Currently we don't have much of a way to distinguish between the recording timestamp and timecode break where a new recording is made versus a rewinding tape.

A variant of https://github.com/mipops/dvrescue/issues/94 could help as we could report the positive or negative discontinuity in the recording timestamp or timecode. Then we could determine the max negative discontinuity of a rewinding tape (there's a limit to how fast a deck will rewind) and use that to classify the reason for the discontinuity.

dericed commented 3 years ago

samples are at https://drive.google.com/drive/folders/1oAMqPIYrVUVHwINSVB7WvfNcTCGOQ6nf. Thx @privatezero

dericed commented 2 years ago

I propose adding @direction and @speed attributes to <frame> and reporting on values that are not equal to the defaults, which would be 1 for direction (forward) and 0x20 for speed (normal playback speed).

interpretation of the speed value is page 22 of http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf. Goes in a range of 0b0000000 - 0b1111000 (for ntsc) or to 0b1100100 (for pal), where 0b0100000 is normal playback speed for ntsc

Mediainfolib already reports these values but doesn't interpret them:

0015E6   DRF - Direction:                      Yes
0015E6   SPD - Speed:                          32 (0x20) - (7 bits)
dericed commented 2 years ago

Nudge to @JeromeMartinez as this relates to recent speed and direction work. :)

JeromeMartinez commented 2 years ago

I propose adding @direction and @speed attributes

Is it important to differentiate? I feel it is too many attributes for only one thing, so I suggest @speed either negative or positive e.g. "-32" for reverse playback.

dericed commented 2 years ago

It's not. It can be one value. I'd consider non-playback speed frames in a captured file to be an error in most instances. So would like the xml to depict it and dvrescue merge to have an option to filter them out.