[B. Rordin]

To all of those:

mt -f /dev/nst0 setpartition 0
mt -f /dev/nst0 setpartition 1
mt -f /dev/nst0 partseek 0 0
mt -f /dev/nst0 partseek 0 1


I get:

/dev/nst0: Invalid argument


I’ve tried with both the bad tape and another good working tape. Is this the correct way to use setpartition?

BTW I tried to dd from the bad tape’s index partition and this is what I got:
# dd if=/dev/nst0 of=file0 bs=524288
(empty file)

# dd if=/dev/nst0 of=file1 bs=524288
[?xml version="1.0" encoding="UTF-8"?]
[ltfsindex version="2.2.0"]
[creator]QUANTUM LTFS 2.2.0 - Linux - ltfs - Unmount[/creator]
[volumeuuid]3fe76962-877a-48fc-b690-4fad2db5daf0[/volumeuuid]
[generationnumber]86[/generationnumber]
[updatetime]2016-01-14T15:22:11.000222042Z[/updatetime]
[location]
[partition]a[/partition]
[startblock]5[/startblock]
[/location]
...etc. This looks like the index of the tape.

# dd if=/dev/nst0 of=file2 bs=524288
(empty file)

# dd if=/dev/nst0 of=file3 bs=524288
dd: reading `/dev/nst0': Input/output error


So basically I’m missing the label and and the xlm after it which somehow got overwritten.

[B. Rordin]

[Martin Greenwood] “I assume you have tried the ltfsck tool to try to recover the index?”

Sure, but the tape I’m trying to recover appears as it have no index partition at all – it doesn’t mount so ltfsck just fails. It says : Cannot read ANSI label: expected 80 bytes, but received 0. I’m sure the data is still there because I recorded the tape so even if the index partition is somehow gone the data should be there.

Have in mind that the output I gave in my original post is all from a good tape I’m playing with while trying to figure out a solution. My understanding so far is that I must somehow rewind forward the tape to the data partition beyond the EOD marker on the index partition and just dump it to a file. The problem I cannot go beyond the EOD marker using mt.

[B. Rordin]

I did a check with SD tiff file with known RGB values outputed on a Mac and PC Combustion via SDI. The Mac gave slightly darker picture. Is it Combustion’s fault or Decklink output compoment’s fault or is it Quicktime?

Please guys we really need to clear this up! All this codec issues and inconsistency on Mac and PC are not good for our crossplatform workflow at all… Any inside information will be really useful.

[B. Rordin]

Thanks! Is there a quick way to relink the renamed media files in FCP or it should be done manually?

[B. Rordin]

I just did the same in Shake. The results are different again:

Pixel 1
Mac / MOV: 85/71/82
Mac / DPX: 85/71/81
PC / MOV: 162/157/214
Shake / MOV: 85/72/81
Shake / DPX: 134/117/130

Pixel 2
Mac / MOV: 509/485/511
Mac / DPX: 507/483/908
PC / MOV: 682/683/783
Shake / MOV: 504/483/511
Shake / DPX: 578/556/579

So what do you think?

[B. Rordin]

It should have less color resolution but I think that it shouldn’t have any visible hue shifts amd gamma changes.

[B. Rordin]

Thanks for the suggestion but in my case it doesn’t work. My output needs to be 4:3 cropped not leterboxed as the decklink downconvertor allows and on top of that decklink resize looks more blurry than the fcp5 resize set at best setting in the sequence properties. I’ve made direct compare between the two and for me it’s not acceptable.

[B. Rordin]

The problem is not only with combustion. Opening Blackmagic clips in shake gives similar results.

[B. Rordin]

I have this problem with HD footage captured thru FinalCut Pro w/ Blackmagic HD card. Yes, FCP reads files correctly, Combustion reads files correctly, no problem so far…. UNTIL I tried recompressing 200 captured clips using Sorenson Squeeze. It was showing wrong framerate and all clips were messed up after compression loosing a couple of frames at the end or showing wrong frame rate. That’s a really annoying and stupid bug. I needed to process all my files 1 by 1 manually in combustion wich removed the problem and then Squeeze was fine. Really annoying bug.