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 before it experienced a few bad sectors; shortly after, it stopped responding to commands.
- Sample #4 has not yet reached the 2,000 read/write cycle mark; it is currently expected to get there sometime in November 2025.
- Sample #5 is still in the package, waiting to be tested.
October 19, 2025