Gigastone 4K Camera Pro 32GB

Gigastone is a brand that seems to show up frequently in Amazon searches — and there’s at least some evidence that they’re trying to work their way into the American retail market as well. And since they have multiple lines of cards, I thought it would be a good idea to test out more than just one. (As of this writing, I’ve also tested the Gigastone Full HD Video 32GB.)

This card fails the criteria that I set out for determining what’s considered a name brand card, primarily for one reason: the product name (in the CID register) is set to hex 3030303030 (or ASCII 00000). They don’t qualify as knockoffs — which means that I’m going to consider these to be off-brand cards.

It turns out that this one is decent in terms of performance: with the exception of sequential write speeds, all performance metrics were at least a little above average. This card bears the U3, V30, and A2 marks; unfortunately, my results seem to indicate that it doesn’t qualify for any of them. I’ll throw in my standard disclaimer here: my performance testing methods don’t align with the ones prescribed by the SD standard; it’s possible that these cards would have done better had they been tested under proper conditions.

On the endurance front:

  • Sample #1 was doing just fine up until round 4,666, when the “permanently write protected” bit in the CSD register got flipped — exactly why it got flipped, I don’t know. However, I decided to declare the card “dead” at that point.
  • Sample #2’s first error was a write failure, affecting 8 contiguous sectors, during round 949. It went for another couple thousand read/write cycles without any additional issues; but then, during round 3,684, a couple hundred thousand sectors more failed to validate correctly. It only lasted until round 3,725, when the card made itself read-only. By the time it got to that point, only about 0.4% of the card’s sectors had been flagged as “bad”.
  • Sample #3 survived just 4,265 read/write cycles before it experienced a few bad sectors; shortly after, it stopped responding to commands.
  • Sample #4 survived just 4,547 read/write cycles before it made itself read-only. It had not experienced any errors prior to that point.
  • Sample #5 has survived 9,456 read/write cycles so far.

June 2, 2026