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: libFLAC 1.2.1 20070917 - piping problems with 6ch files? (Read 2688 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

libFLAC 1.2.1 20070917 - piping problems with 6ch files?

I am not sure if it's a problem with foobar2000 or libflac, since I don't really know how to test piping outside foobar

I have a 6ch, 16Bit, 48kHz wave file with a length of 00:02:23 and a bitrate of 4608kbps (as displayed by foobar)
When I try to convert it to flac (foobar command line: flac.exe --verify -8 - -o %d), it results in a 6ch, 16Bit, 45kbps file with a length of 02:04:17

The file plays fine up to the correct length, followed by silence.

If I convert the same file via command line (flac.exe --verify -8 file.wav), everything works fine.
I also tried to convert the file to wavpack from foobar and it converted correctly, which makes me think it's really a flac issue and not foobar.

Am I missing something?

libFLAC 1.2.1 20070917 - piping problems with 6ch files?

Reply #1 –
Default settings for FLAC in foobar2000 include --ignore-chunk-sizes option. Either add it or use "%s -o %d" instead of "- -o %d".

libFLAC 1.2.1 20070917 - piping problems with 6ch files?

Reply #2 –
Hmm, I don't remember removing that one, but it's been ages since I touched my converter options.
This seems to have fixed it, I don't really understand the issue though. Is the encoder getting data in chunks and basing the playtime off the number of chunks/their size?

libFLAC 1.2.1 20070917 - piping problems with 6ch files?

Reply #3 –
I ran a built-in Google search on foobar2000 FLAC ignore chunk sizes for you: http://www.hydrogenaudio.org/forums/index....showtopic=80017

This post provides some explanation, albeit incorrectly blaming foobar2000 – or, at least, using ambiguous language that implies that – when the application has no culpability at all:
Quote from: GeSomeone on
foobar2000 stopped to provide the accurate file length to the encoders, I think this thread gives you a clue.
[…]
This only matters when encoding from stdin (which is the most efficient), when you do "flac -s -8 %s -o %d" --ignore_chunk_size is not needed because Flac can see the exact length of the temporary file.

The thread linked in my quote contains this post, which explains the issue, why foobar2000 (or any other intermediary) cannot possibly be to blame, and its solution:
Quote from: Peter on
You need to encode through temp files (%s) instead of stdin. This simply can't be fixed with stdin because length of source file is not always known accurately without having decoded entire file in advance; encoders should expose additional switches to handle "truncated" WAV files like wavpack does.
…and as flac.exe now does, in the form of --ignore-chunk-sizes, making the necessity of encoding via temporary files a thing of the past.