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: Bug? The bloated FLAC seektable I got by forgetting "--ignore-chunk-sizes" (Read 805 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bug? The bloated FLAC seektable I got by forgetting "--ignore-chunk-sizes"

Upon fiddling with conversions, I discovered that a silent test signal just grew enormously (relatively speaking), creating a SEEKTABLE that extends far beyond the file itself. After a bit of debugging it turns out that I had forgotten the --ignore-chunk-sizes from custom settings.
That was (to me) an unexpected effect of that setting. Replicated on 1.6.14 and a couple of 2.0 betas. 

* This isn't supposed to happen, no?!
* Even if user is to blame, this isn't outright easy to fix, so ... new feature request: an improved "Fix FLAC seek table"

From the metaflac output, you see the number of samples is < 1.5 million, and seekpoints from number 4 on fall outside that range.
Code: [Select]
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 14 bytes
  maximum framesize: 17 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 1499400
  MD5 signature: 623850d4a4b305f93262d235167f922f
METADATA block #1
  type: 3 (SEEKTABLE)
  is last: false
  length: 43830
  seek points: 2435
    point 0: sample_number=0, stream_offset=0, frame_samples=4096
    point 1: sample_number=438272, stream_offset=1498, frame_samples=4096
    point 2: sample_number=880640, stream_offset=3097, frame_samples=4096
    point 3: sample_number=1318912, stream_offset=4702, frame_samples=4096
    point 4: sample_number=1764000, stream_offset=0, frame_samples=0
    point 5: sample_number=2205000, stream_offset=0, frame_samples=0
    point 6: sample_number=2646000, stream_offset=0, frame_samples=0
    point 7: sample_number=3087000, stream_offset=0, frame_samples=0
    point 8: sample_number=3528000, stream_offset=0, frame_samples=0
    point 9: sample_number=3969000, stream_offset=0, frame_samples=0

[etc!]

Re: Bug? The bloated FLAC seektable I got by forgetting "--ignore-chunk-sizes"

Reply #1 –
It seems to me that whenever this happens, it writes a seektable of precisely 2434 points. No idea why ... ?

Re: Bug? The bloated FLAC seektable I got by forgetting "--ignore-chunk-sizes"

Reply #2 –
This is not really a bug and it's a known issue for FLAC and foobar2000 veterans. See for example https://hydrogenaud.io/index.php/topic,41287.0.html and https://hydrogenaud.io/index.php/topic,58634.0.html.

When you encode using pipes foobar2000 outputs a temporary WAV file that reports maximum length supported by the format. FLAC expects the file to be huge and reserves space for a huge seektable.

The converter in foobar2000 does this partly out of paranoia. It can't know the output file length in advance if DSPs are used or if the input doesn't report accurate length. I think foobar could safely report correct length at least when source is lossless and DSPs aren't used. Though I think nowadays all widely used formats that aren't synthesized report accurate lengths unless the files are corrupted.

Re: Bug? The bloated FLAC seektable I got by forgetting "--ignore-chunk-sizes"

Reply #3 –
Ah. So as far as I understand from the links, the purpose of writing a maximally long seektable, is to avoid another full file rewrite.
If so, rewriting the seektable would be a good thing, provided the extra space is used for padding.
Especially if I have checked off for any sort of metadata transfer after conversion - then, fixing the seektable might very well immediately save a full rewrite. It seems it could be tens of kilobytes to save, if there is at most a thumbnail picture then that would fit.

I have somewhere posted a suggestion that - when a FLAC file is fully rewritten - that it could be padded up to an integer multiple of 4096, since that is the most common file size block; because the space is anyway wasted, why not use it for padding given that one has to do a full rewrite? Only two kilobytes extra on average, but since it is free space and every now and then that would save a full rewrite, so why not.
Seems there is a much bigger fish up for catch.