What does "zero bit padding in the end" mean

Question

I am trying to debug a 3d file format exporter which sometimes exports files that aren't working everywhere(some programs open them some don't). While I was reading the documentation there seems to be a line that I cannot wrap my head around:

6.4 Objects

The objects in each section are serialized as an array of bytes, one after the other. This array of bytes will either be compressed (if CompressionScheme is 1) or it will be uncompressed. If it is compressed, it is compressed as a single chunk of data, not as separate objects. Zero bits must be padded in the end to make the Objects field byte aligned.

The documentation can be found at http://www.j2megame.org/j2meapi/JSR_184_Mobile_3D_Graphics_API_1_1/file-format.html

And this is the current code I am using:

protected void write(M3GOutputStream os,ArrayList table) throws IOException
{
    ByteArrayOutputStream baos=new ByteArrayOutputStream();
    writeObjects(new M3GOutputStream(baos),table);
    uncompressedLength=baos.size();
    byte data[]=baos.toByteArray();
            if(!M3GToolkit.useZlibCompression)
            compressionScheme = UNCOMPRESSED;
    if (compressionScheme==ZLIB)
    {
        Deflater deflater=new Deflater(Deflater.BEST_COMPRESSION,false);
        deflater.setInput(data);
        deflater.finish();
        byte compressed[]=new byte[data.length<<1];
        int length=deflater.deflate(compressed);
        data=new byte[length];
        System.arraycopy(compressed,0,data,0,length);
        deflater.end();
    }
    os.resetAdler32();
    os.writeByte(compressionScheme);
    os.writeUInt32(totalSectionLength=data.length+13);
    os.writeUInt32(uncompressedLength);
    os.write(data);
    os.writeUInt32(checksum=(int)os.getAdler32Value());
}

Take a look at e.g. [Huffman Coding](http://en.wikipedia.org/wiki/Huffman_coding) where the inputs may be fixed size objects such as `byte`s, but the outputs are individual bits. So if you want to store such output in a byte array, you need to do something to deal with the fact that the output bits may not be cleanly divisible by 8. — Damien_The_Unbeliever, Jun 06 '14 at 07:26
Oh I get it, however if I am packing the data without encoding it then the data can be either float/int/short/byte and all of them divide by 8 exactly, right? — Anton Banchev, Jun 06 '14 at 07:29

score 1 · Accepted Answer · answered Jun 06 '14 at 07:25

1

If you have the binary value of "101", it must be padded to "00000101" assuming an 8 bit value.

Adding the leading zeros will not change the value, however it is needed so the number takes up the entire 8 bits. This is needed to ensure the value stored next to it will be aligned at the start of a byte.

answered Jun 06 '14 at 07:25

Hampton Terry

344
1
13

Ok this was also my thought, however you add the padding in the beginning, in the specification they state that the padding is in the end and 101 != 10100000 – Anton Banchev Jun 06 '14 at 07:27
Depends if they are using big or little endian – Hampton Terry Jun 06 '14 at 07:29
Or if the stream is reading from the string of bits, the leftmost bit will be read first thus is the least significant bit. Therefore padding on the right of the byte will not change the value. – Hampton Terry Jun 06 '14 at 07:30
Hmm it is not specified in the file but because it is java I will assume big endian, thanks for the clarification. – Anton Banchev Jun 06 '14 at 07:31

What does "zero bit padding in the end" mean

1 Answers1