Gigastone High Endurance Pro 128GB: good out of the pouch, different once it has been full

Is the Gigastone High Endurance Pro any good?

Gigastone is a Taiwanese brand that sells a lot of memory cards on Amazon and prints one thing on this one that no other card on my bench prints: TLC, on the card face, in the same weight as the class marks. It is there to tell you what kind of flash is inside, and by implication that it will outlast a cheaper kind. The pouch it ships in tells you nothing else. No speed figure, no class marks, no endurance rating, no warranty term, no capacity disclaimer; a brand name, a window, a barcode label and four corporate addresses. The card face carries the marks, U3, V30 and A1, and Gigastone’s own product page supplies the numbers, Read/Write up to 100/50 MB/s and a five-year limited warranty. The Amazon listing says only up to 100MB/s with no direction attached.

So I bought one, at retail, and ran it the way I run every card on the CKBench corpus: a register dump on a Raspberry Pi to learn who made it, then the full suite on my primary reader including a fill of every byte, then the suite again on a second reader. The second run came back with a write floor half the first one’s. That is the kind of result that is usually the reader’s fault, and this time it was not. Working out what it was took two more runs and a procedure I had never used on a card before, and it is the most useful thing on this page.

What the card claims, and what the card did

Three rows need their reasoning attached. The read miss is real but small. A plain UHS-I card cannot read faster than about 96 to 97 MB/s on any reader, and every 100 MB/s card on this bench lands there, which the rubric treats as met. This card reads 94.5, on both readers, agreeing to 0.2%: it is 2.2 MB/s slower than the bus, and that is the card, not the reader. Three of the four cards on its controller platform do the same thing, as the identity section shows. A1 is not testable on a USB reader, and this card is the second on my bench to pass the A1 read floor on one reader and miss it on the other with the same card, which is the reader deciding, not the card. The 50 MB/s write is comfortably beaten, and the V30 mark held in every state and on every reader, with 1.0 MB/s to spare at its worst.

A pouch that says nothing

The card comes in a foil zip pouch with a red band and a clear window, in a small case with a Gigastone UHS-I SD adapter. The back of the pouch carries a California Prop 65 warning, a barcode label with the retail SKU, recycling marks, Made in Taiwan, four addresses and a copyright line. That is the complete inventory. It is the least a boxed card has told me about itself on this bench, and it is worth setting against the SanDisk High Endurance blister, which prints an hours ladder, the bitrate the hours assume, a definition of a gigabyte and the warranty on its back panel. Price and disclosure do not track each other in memory cards, and this pouch is the widest gap I have seen.

The one useful string on it is the SKU on the barcode label, GS-MSD-128GB-12-1PK-B, which identifies the listing rather than the part inside. Everything else this review has to say about what is inside came from the card’s own identity register, further down.

A nine-second saw-tooth, and a floor that depends on the card’s history

This is the panel that decides a video class, and on this card it needed four runs to read correctly. The trace below is the scored run: run 3, on my primary reader, after the card had been written end to end and emptied again, which is the state a dash cam keeps a card in. What you are looking at is two things at once. The regular pattern, about three seconds near 82 MB/s and six near 45, is the card’s write cache filling and emptying; every cached card does this, and this one just has a small enough cache, about 220 MB, that a one-second sampler can see the seam. The irregular part, the drops to 23 MB/s that last one to six seconds, is what changed after the fill. They set the worst ten seconds at 31.0, and that is the number the V30 verdict rests on.

Here is why it needed four runs. The first run, on a sealed card, drew the saw-tooth with no drops at all: worst ten seconds 59.6, lowest single second 44.0, the cycle so regular that its nine-second autocorrelation is 0.96, the cleanest periodic trace I have recorded. That run also filled the card, every byte, and the fill’s own trace is where the change began. The second run, ten hours later on a second reader, came back at 32.3 with the drops. The third, back on the first reader, came back at 31.0 with more of them. Same card, same slot as the clean run, half the floor.

The one-second sampler makes the fresh run’s 59.6 slightly lucky, for what it is worth: a nine-second window over the same data reads 60.5 and an eleven-second window 58.6, because ten seconds spans just over one cycle. The honest fresh figure is “about 55 to 60”, and the fourth run below landed at 54.5. The used figure is not phase-sensitive at all; the drops set it, and they read 31.1, 31.0 and 31.1 across the same three window widths.

The floor gave way in the last third of the fill

The whole-card fill on run 1 is 2,106 one-second samples, and cutting it into 150-second slices shows exactly when the card stopped being the card from the first five minutes. For the first 80 GB, the worst ten seconds of every slice sits between 58.5 and 59.3 MB/s, the same floor as the sealed-card run. Past 82 GB it slips to 55.4; past 91 GB to 49.8; and over the last 25 GB it sits at 45 to 47, with the first second under 35 MB/s arriving at 100 GB written and the fill’s lowest second, 23.07, at 122.7 GB. That value, 23.07, is the identical lowest second the used runs produced. The average barely moved, 60.5 to 56.4; what changed was the floor.

I scanned every whole-card fill on file for the same thing, comparing the worst ten seconds of the last quarter of each card against its first half. Every SanDisk, VIOFO, Vantrue, Kioxia, Samsung and Lexar 128 GB card holds its floor within 3% from the first file to the last. Two cards do not: this one, and the Botslab 128GB, which fell from 51 to 42. The Botslab is the other nine-second saw-tooth card on my bench, and the identity section explains why that is not a coincidence.

I erased it properly, and the floor came back

A card reader connected over USB never tells a memory card that a deleted file is gone. The operating system deletes the directory entry; the card’s controller still believes every block it wrote is holding valid data. A card straight from the factory has a full pool of never-written blocks and writes into them without pausing. A card that has been written end to end has only the small reserve its controller keeps back, and every new write means clearing an old block first, in the foreground, while the recording is happening. That was my candidate explanation for the drops, and it makes a prediction: a real SD erase, the command a native SD host can send and a USB reader cannot, should give the card its factory floor back.

So I put the card in a Raspberry Pi, whose slot is a native SD host, confirmed its serial number against its register dump, read three one-megabyte samples off it and hashed them, and issued a whole-device erase. The card discarded all 125,069,950,976 bytes in 26.5 seconds, which is the controller clearing its map rather than grinding through flash, and the same three samples read back as solid ones, the value this card’s registers say erased data reads as. Then a quick format on Windows with the SD Association’s formatter, which reproduced the factory layout to the byte, and the suite again on the primary reader.

Run 4 is run 1 on every statistic. The steady state is back at 61.3, the nine-second cycle is locked again, the sequential passes are flat again where the used runs had a sag in the middle pass, the settle finished in 60 seconds like the first run rather than 90 like the used ones, and not one second of the five minutes dipped under 40. The worst ten seconds landed at 54.5 rather than 59.6, which is one slightly deeper slow phase at 44 seconds and the same scoring band. The 204 GB I had written to the card had not changed the card. What had changed was the controller’s idea of what was on it, and telling it the truth put the speed back.

Three things follow, in order of how much they should change what you do. First, the slower floor is not wear. It arrives the first time the card is filled, it does not get worse with more writing in any way an erase does not undo, and nothing in this review touches the endurance the TLC mark implies. Second, a dash cam never erases. In-camera formats and every format you can do through a USB reader, including the one I just did, write filesystem structures and leave the controller’s map full, and a dash cam then keeps the card written end to end and overwriting, permanently. So the used state is the state this card lives in, and 31 to 32 MB/s at its worst ten seconds, 23 at its worst second, is the honest description of it in service. That is still V30 and still three and a half times what a 4K dash cam writes. Third, the fresh floor is reachable on demand, but only from a native SD host; a computer with a built-in slot that is a real SD controller rather than a USB reader can do it, a Raspberry Pi can, and a card reader cannot. What each kind of format actually does to a card, how the same whole-card write went the other way on a Samsung, and which cards on the bench never showed the drop at all are in the used-card explainer.

What scattered writes do to it

Loop recording is not one long write. It is a long write interrupted constantly by small ones: event clips, directory updates, overwrites of the oldest file. Random 4K writes are the bench version of that abuse, three twenty-second passes of it, and the question is whether the third pass is as fast as the first. On the scored run the answer is that it got faster: 506, 536 and 550 write IOPS, no fade, and the card was back at its full sustained rate in the first ten-second window after the churn leg. The fresh runs did the same, 563 rising to 600 on the sealed card. The second reader’s used run was the only one that faded, 563 to 514, and the rubric scores the primary reader.

The absolute numbers are modest. 500 to 600 write IOPS and 1,300 to 1,650 read IOPS put this card in the lower half of the bench for small scattered writes, near the Botslab and the TeamGroup and well under the SanDisk High Endurance. That is a fair description of a card built for one long stream, which is what a dash cam asks of it. What the rubric scores, and what matters for loop recording, is whether the churn costs the card anything it does not get straight back, and here it did not.

Every byte, written and read back

The bench wrote 117 files of unpredictable, dedup-proof data until the card was full, 125,035,741,184 bytes, then read every one of them back and compared. Zero mismatched bytes. Zero read errors. The read-back ran at 96.5 MB/s, the same bus-limited figure the card reads at everywhere, and the whole card came back in 22 minutes 37 seconds. The write spread across the first, middle and last tenth of the card was 5.35%, which is the fill’s floor giving way in the last third, as the section above showed; the reads spread 1.05%.

125.0 GB is 97.7% of the 128 GB on the label, which is ordinary provisioning overhead and sits inside the 96.7% to 100.1% range every genuine card on this bench occupies. It is a new value on my bench: SanDisk declares 99.9 to 100.1, the Longsys-made cards 98.2 to 99.1, Kioxia and TeamGroup 96.7, the two bundled dash-cam cards 97.4. Windows will show you about 116 GB, because it counts in binary, and that is not a shortfall; the methodology page covers why. Gigastone publishes no usable-capacity figure and no definition of a gigabyte anywhere, so there is no printed number to hold it to beyond the 128.

Among the coolest cards on the bench

Gigastone publishes no operating range for this card, so the rubric scores it against the 85 °C most cards are rated to. At the end of five minutes of uncooled writing the thermal imager read 125 °F, or 51.7 °C, on the card body at the reader’s slot mouth, on three separate runs across both readers. The fourth run, after the erase, read 132 °F (55.6 °C) at the same 76 °F ambient, and the rubric takes the highest reading on file. Either way it is a cool card: of the 128 GB microSD cards on this bench that write faster than 25 MB/s, only this one and the TeamGroup peak under 135, and the SanDisk High Endurance units run at 151 to 157.

The drops in the write trace are not heat. They appear in the first minute of the used runs, before the card has warmed, they are absent from a fresh card at the same temperature, and an erase removes them without changing anything thermal. The reading is a floor rather than a peak, because the imager sees the part of the card outside the slot and the controller is inside it, and that caveat applies to every card on this bench equally. Heat cost this card nothing on any run, and it has more headroom than almost anything else I have measured.

What TLC on the card does and does not tell you

TLC means each flash cell stores three bits. The cheaper alternative, QLC, stores four, and wears out sooner; the expensive one, MLC, stores two and lasts longer still. Gigastone sells an MLC-marked industrial line above this card, so the mark is partly a tier label inside its own catalogue and partly a shot at unnamed QLC competitors. It is the first NAND-type declaration I have seen printed on a card face, and I want to be exact about what this bench can do with it, which is nothing directly. No SD register reports the flash type. No class mark depends on it. No test in the suite distinguishes three bits from four. It is a statement about construction, and it stays one.

What the bench can do is describe the behavior and let you judge whether it is consistent with the label. Three things it saw. The saw-tooth in the write trace is the card’s cache, a slice of the flash run in single-bit mode as a buffer, filling at 82 MB/s and emptying into the main array at about 50. Every cached card writes this way; a QLC card with the same cache would too, so the pattern neither confirms nor contradicts the mark. The drops after a fill are the controller, not the cells; any flash type behind a controller that reclaims in the foreground would show them, and the erase proved they are not wear. The one number that leans toward the label is the rate the main array accepts data at: about 50 MB/s while the cache is emptying, and about 60 across a 125 GB fill of fresh flash. A four-bit array on a UHS-I microSD typically writes well under 30 direct, and the identity section below has a card on the identical controller that writes at 5 when its cache is full. That is consistent with TLC. It is not proof, and I am not scoring it.

The larger point is what the mark is standing in for. SanDisk prints an endurance rating on its High Endurance box, in hours at a stated bitrate, which a reader can at least turn into arithmetic. Gigastone prints a construction claim and, on its product page, no hours and no terabytes at all. Neither can be verified in a review, but one is a number and the other is a description of what is inside the package, and a card called High Endurance Pro is the third brand on this bench, after VIOFO and Vantrue, to sell endurance without stating any.

Who actually makes the Gigastone High Endurance Pro

Every SD card carries a 128-bit identity register, written at the factory, that a USB reader cannot show you but a native SD host can. I read this card’s on a Raspberry Pi. The manufacturer ID is 0xFE, which is not a registered manufacturer code, the OEM field reads 42, the product name field reads SD padded with nulls, and the revision is 2.0. I had seen every one of those before. They are, field for field, the identity string the Newegg TeamGroup 128GB reports, the card I bought as a cheap negative control in August, made twenty-one months apart. And the SD Status register, the block that declares the card’s classes and its erase geometry, is byte-identical across four cards on my bench: the TeamGroup, the Botslab, the FitcamX, and this one.

A shared manufacturer code is weak evidence on its own; 0xFE could be a default several module houses never bother to change. What lifts it here is that the four cards behave like one platform and differ in exactly one way. All four accept data into their write cache at the same 80 to 82 MB/s. Where they part is what happens when the cache is full and the main array has to take the data itself.

The TeamGroup, on the identical identity string, falls to 5 MB/s when its cache is full. This card holds 50 on a fresh card and 35 to 47 used. Whether that gap is the flash type the face declares, the grade of the flash, the number of dies or the firmware, the bench cannot tell, and I will not pretend it can. What it can say is that the TLC mark sits on the best-behaved card of the four on this platform, that three of the four read a step under the bus ceiling where every other card on my bench reaches it, and that the Botslab’s saw-tooth, which its own review treated as a fault of that card, is the platform’s cache and not the card’s.

Two things I am careful not to say. I do not know who the module house is; Made in Taiwan is on the pouch, and TeamGroup is a Taiwanese brand, and that is as far as the evidence goes. And the four cards do not share a byte count: four different declared capacities on one platform, so the capacity a card delivers belongs to its flash lot, not its controller. A fifth card has since matched this one to the byte, and under a different manufacturer ID: the PNY Premier-X 128GB declares the same 125,069,950,976 bytes, carries the same three capability registers, and reports 0x74 in the identity field, which is the first time the platform has turned up behind a number other than 0xFE. My manufacturer ID register carries all four entries.

How the 4.5 breaks down

One decision in that block should be visible. This card has two floors, and I had to choose which one to score. The rubric’s own instinct, when two readers disagree, is to take the lower figure and say so, and the used state is also the one a card lives in once it has been in a camera for a day. Scored fresh, the sustained row would be a 4 and the overall would still be 4.5. I chose the used state and put the fresh figure beside it, and the erase section is the receipt for both.

The bottom line

This is a good V30 dash cam card that was honest with me once I asked it the right question. It verifies every byte, it beats its write figure, it holds its marks on two readers in both of the states a card can be in, and it runs cooler than nearly everything else here. Its read is two megabytes a second short of the bus. Its cache is small enough to see. And once it has been full, which in a dash cam is always, its floor is 31 rather than 59, still V30, still three and a half times what the camera asks, and recoverable in half a minute from a native SD host if you ever have a reason to want the fresh figure back.

The TLC on the face is the least useful thing on it. Not because it is false, and the numbers lean its way, but because a construction claim on a pouch that prints no endurance figure is asking you to take the important part on trust. If Gigastone put an hours figure and a bitrate on the pouch, this would be a 128 GB endurance card I could recommend without a paragraph of caveats. As it stands it is one I can recommend with them, and the caveats are the review.

Sample size: one unit, purchased retail from Amazon on 11 September 2026. Four runs on two readers, 16 to 18 September 2026, under CKBench protocol v1.20; the fourth after a full SD erase on a Raspberry Pi.

Disclosure: I bought this card at retail from Amazon on 11 September 2026. Gigastone had no involvement in or knowledge of this review, saw no result before publication, and had no opportunity to influence any number on this page. This post contains affiliate links. As an Amazon Associate I earn from qualifying purchases, at no extra cost to you. Affiliate links like these and my YouTube channel are what keep the site running.