Quote:
Originally Posted by Haldi4803
mhmm, thats because they created a new data format for SDXC and we're reformating to SDHC standard?
|
It's not about the reformat. It's lower than that.
When id comes to SDcard readers, micro or normal, there are basically two types:
Type 1:
Hardware/firmware-driven, that uses it's own hardware to manage the basic functions of the SD-card and presents is as an UMS device (USB Mass Storage)
The benefit from those readers are less utilisation of the main CPU followed by higher throughput.
The backside is the limited support of what standards it can use.
Type 2:
Software/"dumb" reader. It'll just provide a "physial" connection to the underlying USB-system, and presents it "as is": a SD-card flash memory.
In this "dumb" mode, the Operating system must provide all the routines in order to communicate properly with the attached SD-card.
The benefit with those are full range compatibility with future standards, but it depends on software, drivers and the main CPU, which might result in slightly lower speeds and "sluggishness" as the IO-operations increases.
However, if the OS and the SDHC/SDXC drivers in question is poorly optimised, the hit on the CPU can be drastically high whenever a read/write occurs.
So, which one is prefered then?
It's up to the manufacturers of the hardware and the operating system.
In our case here, Android can use both UMS devices, as well as generic/default SDHC and SDXC flash cards.
In my opinion, the type 2, "dumb" readers, are the "best" ones.
The only limitations of what cards these readers can use, is only limited by the operating system and the kernel modules/drivers provided.
And the "load" on the CPU as generally so small it's often neglectable, provided the drivers and OS is well optimised.
Which type the X10 smartphone uses I cannot tell.
I simply don't know, but it sounds promising, as there haven't been any "corrupted data" reports from the few who are using 64GiB cards...
... yet!
If the X10 smartphone does utilise the type 1 reader, the firmware/hardware based one, it might "kick back", as data stored beyond the 32 GiB limit of the readers limitation, might just "disappear into the void", never reporting any errors.
Users might notice this first when they try to access the previous stored files and finds out the content returned are just a stream of nulls. (null = digital void, nothing, nada, true zero, blank)
If and When this happens, only time can tell.
Someone has to try fill the card "to the brim", and copy back the content verifying everything is correct and proper.
Not just the filenames and filesizes, but also the content itself. (Checksum methods should suffice)