Convertir MiB a GB

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

Un gigabyte son mil millones de bytes, en el sentido decimal que usan los fabricantes de discos, las tarifas de datos y los tamaños de vídeo.

El factor es 0,001049, y casi nadie lo lleva encima. Redondeado a 0,00105 se desvía un 0,14 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 MiB.

Ese es el dato que interesa antes de redondear: no el error en sí, sino a partir de dónde deja de ser despreciable. Por debajo de ahí el factor corto es el sensato; por encima, usa el campo de arriba, que no redondea hasta el momento de escribir el resultado.

Un MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 0,001 GB y 0,001 GB —un 4,9 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 4,9 %. Un disco vendido en MB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 0,001 GB donde la caja ponía 0,001 GB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

Los dos números de esta comparación vienen de mundos distintos. La cifra de consumo la produce un aparato contando bytes para sus propios fines, y los aparatos cuentan en potencias de 1.024: el gasto por aplicación, las descargas y los tamaños de archivo salen en mebibytes sea cual sea la letra que venga detrás. El techo es una cifra comercial —una tarifa, un plan, una capacidad impresa en una cajita— y las cifras comerciales son decimales.

De modo que la comparación que casi todo el mundo hace, mirar un número y recordar el otro, se equivoca sistemáticamente en un 4,86 % y siempre en la dirección cómoda. Un total de 4.800 frente a un tope de 5.000 parece dejar un cuatro por ciento de margen y en realidad se ha pasado un 0,7 %. Las unidades se parecen lo bastante en el nombre como para invitar a la comparación y difieren lo bastante como para estropearla.

La multiplicación que dan casi todas las páginas es que 1.000 MiB son 1,049 GB, y para este lector sirve mejor la división: 953,67 MiB agotan un gigabyte. Cinco gigabytes son 4.768 MiB, diez son 9.537 y veinte son 19.073. Esos son los techos contra los que hay que comparar una lectura del aparato, y cada uno queda unos puntos por debajo de la cifra redonda que cualquiera daría por supuesta.

La versión de andar por casa consiste en quitar un cinco por ciento al plan antes de comparar. Un tope de 5 GB se comporta como 4.750 en una pantalla que muestra mebibytes, y uno de 50 GB como 47.500. Es suficiente para decidir y bastante fácil de hacer mirando un teléfono, que es la situación en la que hace falta esta conversión casi siempre.

Sería cómodo que aplicar el factor 1,048576 hiciera coincidir la cifra del aparato con la del proveedor, y no lo hace. El proveedor mide en otro punto: su contador ve cabeceras de protocolo, retransmisiones y establecimientos de conexión que el aparato no atribuye a ninguna aplicación. Muchos redondean cada sesión hacia arriba hasta un incremento de facturación, de modo que cien sesiones cortas cuestan más que una larga con la misma carga útil. Unos excluyen sus propios servicios del recuento y otros no.

Así que la conversión responde a una pregunta más estrecha de lo que parece. Le dice qué significa su total en las unidades del proveedor; no le dice qué registró el proveedor. Si después de convertir los dos números quedan a unos pocos puntos porcentuales, la diferencia es de medición. Si quedan a un veinte por ciento, está pasando otra cosa y ninguna aritmética de unidades va a encontrarla.

Los planes de almacenamiento en línea repiten la estructura y añaden una segunda resta. La cuota es decimal, el cliente de escritorio muestra binario y el proveedor cuenta además contra el total cosas que el usuario no considera archivos suyos: versiones anteriores de documentos, la papelera durante su período de retención y, en algunos servicios, los metadatos de cada objeto. Nada de eso es un abuso, pero explica por qué la carpeta sincronizada mide menos que la cuota consumida.

El orden que evita sorpresas es convertir primero y preguntar después qué más se está contando, porque son dos cuestiones separadas y solo la primera tiene respuesta exacta. Vaciar la papelera y limitar el historial de versiones suele devolver más espacio que cualquier ajuste de unidades, y conviene comprobarlo antes de contratar el escalón siguiente.

Cuando el total sale de sumar muchas cifras mostradas en pantalla, el redondeo hace más daño que las unidades. Una lista de doscientos archivos, cada uno con un decimal en MiB, arrastra hasta 0,05 MiB de redondeo por pieza, así que la suma puede irse diez mebibytes antes de convertir nada. Eso es más que la corrección del 4,86 % sobre un total pequeño, y además es invisible.

La solución es la misma que en el resto de esta familia: sume los bytes si los bytes están disponibles y convierta una sola vez al final. Cuando solo existen las cifras mostradas, trate el resultado como aproximado y dígalo, en lugar de convertir una suma de números redondeados y presentar tres decimales como si se hubiesen medido.

Ignorar la distinción no es una equivocación simétrica. Leer una cifra en mebibytes como si fuera megabytes subestima la cantidad, y leer un plan decimal como si fuera binario sobreestima el margen. Los dos errores apuntan al mismo sitio, y se suman cuando alguien comete los dos a la vez, que es el caso corriente.

Un total de 9.000 MiB frente a un plan de 10 GB parece dejar una décima parte del plan sin gastar y en realidad son 9,44 GB, con 0,56 de margen. Esa es la forma del problema entero: los números están lo bastante cerca para compararlos directamente, la comparación siempre sale optimista y la corrección nunca es lo bastante grande como para resultar evidente a posteriori.

Muy pocas interfaces de consumo escriben MiB. Escriben MB y calculan en mebibytes, que es un convenio heredado de décadas de sistemas operativos haciendo lo mismo. Rara vez hay un ajuste para cambiarlo y rara vez existe documentación que lo diga, de modo que al lector le toca deducir la base por el contexto.

La deducción fiable es la capacidad. Si un aparato con una tarjeta de 64 GB informa de un total en torno a 59,6, cuenta en binario y todas las demás cifras de esa pantalla también. Si informa de 64,0, cuenta en decimal y no hace falta convertir nada. Una sola lectura de un solo número decide cómo interpretar todo lo que ese aparato vaya a mostrar en adelante. Con una tarjeta de 128 GB la referencia son unos 119, y la merma es del 7,37 % porque el escalón giga está un peldaño más arriba.

La partida más grande del consumo de casi cualquiera es el vídeo, y el tamaño de un vídeo lo gobierna una tasa de bits que no se ve por ninguna parte. Una hora de reproducción a 5 Mbit/s son 18.000.000.000 de bits, es decir 2,25 GB, o unos 2.146 MiB. A 3 Mbit/s la misma hora son 1,35 GB y a 8 Mbit/s son 3,6 GB. Los ajustes de calidad mueven esa cifra mucho más de lo que la moverá jamás ninguna conversión de esta página.

Es también el punto donde el bit y el byte se confunden con más facilidad, y ahí la confusión vale un factor de ocho y no unos pocos puntos. Una tasa escrita Mb/s son megabits y una escrita MB/s son megabytes. Cuando se planifica un consumo alrededor del vídeo, fijar la tasa de bits y dividir entre ocho es el paso que determina la respuesta; la corrección de decimal a binario viene después y es un retoque encima.