Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: flac.exe weirdness: What are these extra bytes when I recompress silence? (Read 822 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

flac.exe weirdness: What are these extra bytes when I recompress silence?

The bytes are not important - curiosity is. And so I took a CD of test signals and recompressed using flac --best -p -e --force.

This silence file of course, screamed at me that it came back twice as big. And that is because of padding, sure fair enough, but no matter what I did to remove padding with fb2k and mp3tag, it came back ... bigger than the original. Inspecting it with a text editor it is the very beginning before the actual tags. So there is something that something (fb2k? dBpoweramp?) managed to make the file smaller back then ...?

Furthermore, recompressing it more times - just to try different FLAC versions - it came back "wrote 14590 bytes" at alleged ratio=0.999, repeatedly. That is, recompressing over and over again and it stayed at 14590 and claimed every 14590 to be .999 of the previous 14590. Hey, it is close :-p


On a different note,  --best -p -e made some impact -8 on test signals like the 66 seconds "Frequency check - 800, 1200, 2800 & 5000". It is a quite simple signal of sine, another sine, etc - and whatever can improve a flac -8 from 334 to 293 on any signal, I'd say that's a lot. All x64 builds, dunno who made them to be honest.
334 was for 1.3.1 -8;
321 for 1.3.3 -8
294 for 1.3.3 --best -p -e
293 for 1.3.1 --best -p -e (62 bytes better than 1.3.3).
Edit: decoding speed took a hit from 1000x realtime to 970x realtime. *chuckles*

I know I am posting in the FLAC subforum, but out of curiosity, new TAK 2.3.1
356 for -p0
335 for -p0m (that is about on par with FLAC 1.3.1 -8)
315 for -p2
311 for -p4
312 for -p4e (!)
301 for -p4m


High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #1
Where did you get your copy of flac.exe? None of mine do that.

Perhaps check the version number with "-v"...

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #2
Found it!
Evidently they were encoded with --no-seektable .

Question: Is there any way to display the seekpoints of a flac file?  Using metaflac  I can add, but ...

High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #3
metaflac.exe --list --except-block-type=PICTURE file.flac
will displays metadata including seekpoints

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #4
Ewww. What I should have asked for, is to search up those which have seekpoints.
But grepping it should work I guess.
High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #5
Evidently they were encoded with --no-seektable .
That doesn't explain why the seektable takes up half the file, though. Re-encoding your sample file with a recent version of FLAC, the seektable adds only 76 bytes.

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #6
Padding. That part was easy to explain.
High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #7
But where is that padding coming from? I re-encoded the file with several copies of flac.exe using the options you listed and none of them doubled the file size with padding!

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #8
According to https://xiph.org/flac/documentation_tools_flac.html, "The encoder writes a PADDING block of 8192 bytes by default". In addition it adds 4 bytes to indicate that there is padding.

Did you use foobar2000 or something? It seems that it uses --no-padding.

All recompressing using --force:

28615 with -0 and -1 and -2
20419 with -0 --no-padding, shaving 8196 off as expected.
14590 with -3 and -8 and -8 -p -e
6394 with -3 --no-padding and -8 -p -e --no-padding
6318 with --no-seektable, shaving 76 bytes off
6318 with foobar2000
High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #9
Errr what?

foobar2000 version 1.6.6 beta is supposed to add seektables, OK, but 6419 bytes, that is more than flac.exe?!
Again the 25 bytes are not important. Curiosity is. @Peter?
High Voltage socket-nose-avatar

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #10
Did you use foobar2000 or something? It seems that it uses --no-padding.
Nope, just different versions of plain old flac.exe. I get 20419 bytes with "-0 --force" and 6394 bytes with "-3 --force".

But I didn't try using --no-padding, and I notice the file you uploaded already has a small padding block in it. It looks like FLAC was copying that padding block to the output file instead of adding a new padding block. If I recompress the file with --no-padding, the padding block is removed. If I recompress the file again without --no-padding, a new 8192-byte padding block is added.

I get 6287 bytes with "-3 --no-padding --no-seektable".

I found this bug that might explain how the small padding block got there in the first place.

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #11
Strange. I have tried 1.1.4, 1.2.1, 1.3.1, 1.3.2 ... win32 and win64 versions.

The already small padding block is, I guess, due to tags written? Or?
High Voltage socket-nose-avatar

 

Re: flac.exe weirdness: What are these extra bytes when I recompress silence?

Reply #12
The already small padding block is, I guess, due to tags written? Or?
That's possible. If you modified the tags and they got smaller, the application you used to modify the tags will probably choose to insert a padding block to avoid rewriting the entire file.

The combined size of the padding and tags is around 900 bytes, which is much less than the default padding size of at least 4096 bytes, so at some point padding was removed (or wasn't added in the first place).

 
SimplePortal 1.0.0 RC1 © 2008-2021