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: lossyFlac conversion with foobar-> corrupted length value (Read 7524 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyFlac conversion with foobar-> corrupted length value

Hi,

I converted a bunch of flac files to lossyWav/lossyFlac with foobar (1.0.1).

Foobar and Mr.Questionman report a ridiculous high duration and number of samples (see attachment).

Screenshot

Here is the command line I used in foobar:
/d /c E:\p\Audio\lossyWAV_1.2.0\lossywav - --standard --altpreset --silent --stdout|E:\p\Audio\flac-1.2.1-win\bin\flac - -b 512 -5  -T comment="lossyWav aps" -f -o%d

What goes wrong here? How could I (automatically) correct the metadata?

Cheers
johnb

lossyFlac conversion with foobar-> corrupted length value

Reply #1 –
Do you get the correct sample length / duration if you use this command line? :

Code: [Select]
/d /c E:\p\Audio\lossyWAV_1.2.0\lossywav - --standard --altpreset --silent --stdout|E:\p\Audio\flac-1.2.1-win\bin\flac - -b 512 -5 -f -o %d

By the way your command line has a space missing:

Quote
-f -o%d

Should be:
Code: [Select]
-f -o %d

That's all I can think is a problem at the moment.

C.

EDIT: Command line space correction added
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyFlac conversion with foobar-> corrupted length value

Reply #2 –
Carpman, thanks for your answer.
The command line was basically taken from the Wiki:
http://wiki.hydrogenaudio.org/index.php?ti...verter_settings
There the space is also missing ...

However, I added the space, still the same result.

As for the sample count: no it is wrong, i.e. 107 3741 823 in flossy vs. 45 789 041 in flac.
I suppose this is also why the display reports a bitrate of 8kbits/s  ;-)
 

lossyFlac conversion with foobar-> corrupted length value

Reply #3 –
All I can add is that it's odd, as your command line for FLAC is identical to mine apart from:

the "--altpreset" switch and:

Quote
-T comment="lossyWav aps"


So if it's neither of those, then why this happens I haven't a clue.
Perhaps one of the experts will be able to help out.

C.

PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyFlac conversion with foobar-> corrupted length value

Reply #4 –
I removed the --altpreset and -T in the converter setting with unfortunately the same result!

In order to analyze this further, I did the following at the dos prompt:
- converted the original flac to wav
- applied lossywav
- encoded  to flac
=> the resulting flac is correct regarding duration, # of samples, bitrate


So I thought, let's convert the wav by means of the foobar converter with the already mentioned command line.
=> the resulting flac shows again the original symptoms 

I have no clue!

johnb

lossyFlac conversion with foobar-> corrupted length value

Reply #5 –
Looking at the size of the file, the audio data of the output file is as big as it can be in a compliant RIFF WAV file. The input file exceeds the size limit. That is why the audio has been cut short.

lossyFlac conversion with foobar-> corrupted length value

Reply #6 –
Hi Nick.C,

maybe I have failed to describe the screenshot properly.
The first file in the playlist is the flac file, the second is the lossyflac file.
As a matter of fact, the real duration of each is 7min 11s. The first is about 40MB, the second 23MB in file size.

So I don't think the files exceed any limit.

I think it boils down to the question, how this large number of samples is set in the conversion.
The audio in the lossyflac file ends after the 7.11min when playing in foobar.

Cheers
johnb

lossyFlac conversion with foobar-> corrupted length value

Reply #7 –
Hmmmm.... When piping (into lossyWAV, etc.) from foobar the apparent data length is the maximum for the RIFF container. When foobar stops sending audio data then lossyWAV closes and then FLAC closes and writes the size of the audio data into the FLAC header. This looks strange to me as I have never encountered the phenomenon during all of the development period of lossyWAV.

lossyFlac conversion with foobar-> corrupted length value

Reply #8 –
Just a thought, but would it be worth johnb trying the same thing with WavPack or TAK? If they came out okay then it would suggest it's a FLAC issue?

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyFlac conversion with foobar-> corrupted length value

Reply #9 –
Foobar requires "--ignore-chunk-sizes" switch in the FLAC converter setup 

E.g. "flac -s --ignore-chunk-sizes -5 -b 512 - -o %d"

lossyFlac conversion with foobar-> corrupted length value

Reply #10 –
Not for me it doesn't. Unless this is a fb2k version issue. I'm on 0.9.4.5.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyFlac conversion with foobar-> corrupted length value

Reply #11 –
Thanks a lot, that did the trick for me!

I had switched recently from fb 0.9.x to 1.0.1. Previously I think it worked without that option.

johnb