Playback Speed Too Fast

[bishbashbackup]

Here's my setup info:

OS: Ubuntu 22.04 LTS Deck: Sony HVR-M15AE Firewire Card: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) DVRescue: v.0.21.11.20230415 (MediaInfoLib v.23.03)

I'm able to capture using DVRescue on the CLI. When I play the tape back on the deck normally it runs at the right speed. However, when I capture with the following command:

dvrescue device://0 -v 9 -m test.dv

The resulting DV file is running too fast! I'm running PAL tapes. The metadata for the DV file say its 25fps as expected. I tried manually setting the playback speed with the --speed flag, but that didn't help.

Any ideas how to fix this? Thanks in advance!

[JeromeMartinez]

Is it running too fast in a classic player e.g. VLC, or only DVRescue GUI? Can you share few seconds of the content? (private email if needed)

[bishbashbackup]

Hi @JeromeMartinez

Just sent you a sample. I was running it in MPV player. But its seems to be the same in VLC and in the DVRescue GUI.

Thanks :D

[JeromeMartinez]

The 3 first frames are from another content (there is a time code discontinuity and rec date/time is present only after the 3 first frames). The 3 first frame have a stereo 48 kHz/16-bit config Other frames have a 2x stereo 32 kHz/12-bit config

None of the tools are able to switch from 1 audio config to another one, so players try to play the 2x stereo 32 kHz/12-bit as stereo 48 kHz/16-bit, reason you have the x1.5 audio playback speed (video playback seems fine, time codes and rec date/time are at 25 fps).

If you cut the first 432000 bytes, the file is correctly played.

In DVRescue, we need to reset the decoder when there is a config change (audio or video!).

[bishbashbackup]

What's causing the first 3 frames to be different, than the rest? I tried capturing a different tape and had the same results. Is there anything I can do to fix this on my end?

[dericed]

Hi @alexhabgood this is a pretty common scenario. Often this happens when a tape is recorded over (like the first recording is x sampling rate and the second is y, but starts a few frame later than x). Or sometimes the tape is the result of a deck-to-deck dub and the record deck starts first so it records some blank frames with a default frame rate before switching to the source tape frame rate. Anyway, dv is a variable sampling rate format.

This is why there's the package part of the program, if you run dvpackager whatup.dv then the output will normalize to the greater sampling rate involved.

[JeromeMartinez]

This is why there's the package part of the program, if you run dvpackager whatup.dv then the output will normalize to the greater sampling rate involved.

@dericed isn't possible to keep the 32 kHz stuff? Because upsampling to 48 kHz will create a (small) loss of quality and it is better to keep the source 32 kHz sample rate there.

[dericed]

@JeromeMartinez, the upsampling is generally from 32 to 48. I'm actually not sure I've ever seen a 44.1 in this project though it's in the standard. The dvpackager options are:

 By default, dvpacakager will preserve the sampling rate of the input DV stream;
 however, if the input contains a mixture of 32000 Hz and 48000 Hz audio, then
 dvpackager will resample the packaged audio to 48000 Hz when muxing to a
 container.

 -3        (Enable this option to keep the sampling rate in its native format.
            Setting this may result in more output files as each change in
            sampling rate will require a new output file. Automatically enabled
            when '-e dv'.)
 -4        (Force all audio to be resampled to 48000 Hz.)

So if dvpackager -3 variable_sample_rate.dv is used, then the packager will output one file per sampling rate transition, otherwise it will normalize to the highest sampling rate. For instance @bturkus had a dv tape of a documentary where most footage was 48 but some silent title cards had 32 audio (or possible these numbers were reversed). Splitting them by sampling rate change to preserve that would have broken up one documentary into many files which would complicate access.

[JeromeMartinez]

I'm actually not sure I've ever seen a 44.1

My mystake, it is 48k, I fixed my comments

So if dvpackager -3 variable_sample_rate.dv is used, then the packager will output one file per sampling rate transition,

I suggest that here, so the 3 first frames are in another file (which may be trashed, seems to be 3 repeated frames from something else) and the real content has no audio config change and any player can play it correctly.

[dericed]

Yes that makes sense to me here, though in some situations like @bturkus's example the mixed content is meant to be kept together.

[bishbashbackup]

Thanks for the input @dericed & @JeromeMartinez

I had a look at the first three frames from the capture and they are all just blank grey. However, I'd started the capture midway through a single video recording, so the grey frames were not from the tape itself.

What seems to be happening is that the tape deck was initially set in 48k mode, but the tapes are in 32k. When I initiated the DVRescue capture it started running the tape deck, but there was a bit of lag before it auto switches the audio sampling to 32k mode. This resulted in DVRescue capturing 3 grey 48k frames at the start of the video, which subsequently cause the speed issue for the rest of the 32k stream.

When I switched the tape deck to 32k mode, it captured without the speed issue. Furthermore, if I started running the tape through deck before initiating the capture, it also didn't have the speed issue.

So, that's the issue resolved for me! I should've set the tape deck to the right audio sampling rate. User error - apologies. :)

It looks like this has raised a wider issue around streams with variable sample rates. I'll leave you al to decide if/when you want to close the ticket.

Thanks both for the assistance :D

[dericed]

That's interesting. @libbyhopfauf, does this correlate to any of your experience?

Also this seems relevant to https://github.com/mipops/dvrescue/pull/614 which is about adding a method to filter though gray frames out during capture.