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: Foobar skips first track pregap when decoding (Read 15639 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Foobar skips first track pregap when decoding

I spent a good part of today trying to figure out why my FLAC images, when re-creating the original WAV file, were different than the WAV file I used to make the FLAC image from.  It turns out Foobar is bad in it's decompression module.

I use REACT to create a FLAC + CUE image directly from a rip in EAC.  If I save the original WAV file it makes, it is identical to an uncompressed rip from EAC as well.  Same file byte for byte.

If I use FLAC -d <filename> to decompress the FLAC file, the WAV file is identical to the original.  If I use foobar to decompress it to a WAV, choosing either the convert to single file or convert to album images with cuesheets or chapters options, the file is smaller and completely incorrect.

Here is the resulting EAC WAV file comparison.  Sorry, I don't know where to post images to get them to show up.

http://img2.freeimagehosting.net/image.php?09daee89a3.jpg

Now, granted I stuck a CUE sheet within that FLAC file as a comment, but that shouldn't hurt or affect the uncompressed WAV file whatsoever.  So what am I doing wrong, or is Foobar.... uh... fubar'ed?

-Robert

Foobar skips first track pregap when decoding

Reply #1 –
OK, I found the answer to my own problem, but not the fix.  Foobar2000 is broken.

My CD was The Beatles Rubber Soul, which is a CD that starts on index 0.  If I use another CD that starts with index 1 on the first track, it works fine.  Foobar doesn't recreate the original WAV file correctly if there is an index 0 before the first track.  This may also have something to do with the fact that the cue sheet is stored correctly as a vorbis comment, but re-creating it with the decompression within Foobar makes an incorrect CUE sheet file with no index 0 references.

So if you have a FLAC image with an index zero before the first track, do NOT use Foobar to make the uncompressed WAV file.  Just use FLAC -d filename

-Robert

Edit:  See my other post at http://www.hydrogenaudio.org/forums/index....showtopic=43390 for other Foobar related issues.

Foobar skips first track pregap when decoding

Reply #2 –
Were you testing with 0.8.3 or 0.9?
 

Foobar skips first track pregap when decoding

Reply #5 –
Mike Giacomelli: No, that's a different issue

valnar: and I'm not sure, I was just asking. Maybe you can try 0.8.3 and see if it works. It's possible something broke in 0.9's CUE support.

Foobar skips first track pregap when decoding

Reply #6 –
I'm more interested in notifying the developers than going back.  At least I know to use the flac commandline program for decompression.  It's definitely a bug, and reproducible.  Thanks.

Robert

Foobar skips first track pregap when decoding

Reply #7 –
I just re-ripped all my CDs to FLAc for use with FB2k.  I assume this is only a problem if I use CUE?  Otherwise FB2k decoding is fine?

Foobar skips first track pregap when decoding

Reply #8 –
valnar,

in your example you are not using foobar for converting the complete source audio file. Instead you are telling it to convert the virtual tracks that are included in the cue sheet. If you make a single output file it just gathers the pointed audio passages together.

The correct way to handle INDEX 00 is always include it in the previous track except when INDEX 00 is before the first track. Then it is excluded. All standalone HW CD players and track based ripping programs use this system. The only way to hear a possible hidden track before the first track with a HW CD player is to rewind past the start point. In my opinion foobar 0.9 works correctly.

I have a couple of CDs that actually contain audio data before the track one. For extracting separate audio tracks of those hidden tracks that are included in the ripped disc image files I have made custom CUE sheets. (Naturally, the CD drive used has to be capable of ripping audio content before TRACK 01/INDEX 01).

For example, I would change this sheet:

Code: [Select]
TRACK 01 AUDIO
  INDEX 00 00:00:00
  INDEX 01 03:48:35
TRACK 02 AUDIO
  INDEX 00 07:15:45
  INDEX 01 07:16:22


To this:

Code: [Select]
TRACK 01 AUDIO
  INDEX 01 00:00:00
TRACK 02 AUDIO
  INDEX 01 03:48:35


Because of this I don't use embedded cue sheets. I keep them separate. In this way I can always load the source audio file itself without virtual track pointers and convert it separately.

Edit: added a missing word

Foobar skips first track pregap when decoding

Reply #9 –
I use FLAC (well, REACT with EAC) to create my FLAC files from a good rip.  The original WAV file for which this is based from has everything.  Index 0 (if present) to the end.  I keep a copy of the real CUE sheet along with my FLAC file so when I decompress the FLAC, the CUE sheet is available to reference the WAV file and I can burn it completely.

My problem is foobar does not decompress that FLAC file correctly to the original WAV file if that original WAV had an index 0 before track 1.  Yes, I realize it also doesn't extract the CUE sheet properly that I tagged, but it does contain it properly, considering you can view the CUE sheet properly in foobar.  Very weird.  This is why I keep the original CUE handy - to recreate the original CD.

Unless you know of another way to use foobar, I do indeed just highlight all tracks then ask it to create the single WAV file from there.  I don't ever make individual tracks.  I consider this a bug, or at least a missing feature, because the FLAC file is complete as created from EAC.  FLAC as a command line decompressor also make the WAV file correctly, with index 0 "data" before track 1.  Foobar does not.

-Robert

Foobar skips first track pregap when decoding

Reply #10 –
The conversion works just as expected when an embedded cue sheet is used. It converts the exact track passages included in the selection (a cue track starts always from the pointer INDEX 01).

You should use a FLAC file without a cue sheet for including the passage INDEX 00 - INDEX 01 before the first track.

Though, foobar could have these two options for cue tracks:

- Make a separate playlist track (# zero) from the passage INDEX 00 - INDEX 01 of TRACK 01.
- Don't read the embedded cue sheet. Handle a file that contains a cue sheet as a single file.

Either one of these options would make possible to convert the complete disc image file.

Foobar skips first track pregap when decoding

Reply #11 –
So basically, as it stands, foobar is not a replacement for the official FLAC frontend or FLAC itself if you want to convert it an album wav file.  I just didn't know that, but now that I do, I won't use it.

Robert

Foobar skips first track pregap when decoding

Reply #12 –
Functionality of foobar on flac with embedded cue sheet is like the one of flac.exe with "-d --cue X.1-Y.1" options. As it was sayed before it will be good to have some option for switching off parsing of embedded cue to work with such flac just as with ordinary file having vorbis tags.

Foobar skips first track pregap when decoding

Reply #13 –
Quote from: valnar on
OK, I found the answer to my own problem, but not the fix.  Foobar2000 is broken.

...

Foobar doesn't recreate the original WAV file correctly if there is an index 0 before the first track.


Quote from: valnar on
So basically, as it stands, foobar is not a replacement for the official FLAC frontend or FLAC itself if you want to convert an album wav file.  I just didn't know that, but now that I do, I won't use it.


It's interesting that this problem still exists two and a half years later, don't you think? Previously, I used Foobar to convert images to FLAC, but later found out this method introduces too many seektables (it maxes them out at 1217). So instead I chose a workaround, using Foobar to convert images to WAV, then using a separate program for encoding error-free FLACs. Now I find out that every album with an index 00 before the first track was not split correctly by Foobar.

That's two major strikes for Foobar. I'm not waiting for a third. I too will no longer be using it for any purpose beyond playback, and I urge others to do the same if they care for file integrity.

Foobar skips first track pregap when decoding

Reply #14 –
Quote from: Weeping Robot on
Now I find out that every album with an index 00 before the first track was not split correctly by Foobar.
That is a matter of opinion.

foobar2000 ignores 00 indices and has done so since as far back as 0.9.  Given this fact, it should make sense that it would behave this way.

If you want foobar2000 to split on 00 indices (that is to say with gaps corrected) you're going to have to modify the cue sheet.  I made a batch file that will do this a while back.  I think I've posted it to the forum, otherwise I can include it in this thread.

In order to keep the FUD to a minimum, I'm going to rename this topic and move it out of the flac forum since the problem really has nothing to do with flac.

Foobar skips first track pregap when decoding

Reply #15 –
Quote from: greynol on
Quote from: Weeping Robot on
Now I find out that every album with an index 00 before the first track was not split correctly by Foobar.
That is a matter of opinion.

foobar2000 ignores 00 indices and has done so since as far back as 0.9.  Given this fact, it should make sense that it would behave this way.

If you want foobar2000 to split on 00 indices (that is to say with gaps corrected) you're going to have to modify the cue sheet.  I made a batch file that will do this a while back.  I think I've posted it to the forum, otherwise I can include it in this thread.


How is it a matter of opinion? The output from Foobar doesn't match the original image! This is just more irrational behavior from Foobar, and its track record has proven to me that it isn't trustworthy. Who knows what else it might be doing that defies common sense or could compromise file integrity.

And yes, I figured that out, that you have to modify the cue sheet. It's ultimately a rather ridiculous workaround that shouldn't need to happen in the first place - and what of the people who don't figure this out, who don't know any better? They're getting incorrect conversions (just like the original poster and I did until we realized better).

Foobar skips first track pregap when decoding

Reply #16 –
I'm no expert, but isn't this why the cuesheets generated by eac are called "noncompliant"?

Foobar skips first track pregap when decoding

Reply #17 –
Yes, indeed, foobar ignores index0 for the first track.
Even if it´s fed with the correct cuesheet by EAC, not the embedded one.

I recognized this when I ripped Damien Rice "9" which contains a hidden track
at index 0 which showed up in EAC.
Foobar ignores that index 0 and it´s not possible for me to playback this track
as long as I do not put the original CD into the drive.

BTW, the cuesheets of the converter are completely different from the original
if you try to restore them from a flacimage with embedded cuesheet..

Foobar skips first track pregap when decoding

Reply #18 –
>Who knows what else it might be doing that defies common sense or could compromise file integrity.

This is the textbook definition of FUD and I chalk this up to a lack of knowledge in the way foobar2000 handles cue sheets.  This doesn't mean that there is no room for improvement.  I don't think anyone would complain if foobar were to extract the pregap out as a separate file when splitting.  When  converting images, I'm not sure of the best route to take.


>I'm no expert, but isn't this why the cuesheets generated by eac are called "noncompliant"?

No.  Cue sheets for single-file images are compliant.  foobar2000 will not even load noncompliant cue sheets.

Foobar skips first track pregap when decoding

Reply #19 –
Quote from: greynol on
>Who knows what else it might be doing that defies common sense or could compromise file integrity.

This is the textbook definition of FUD and I chalk this up to a lack of knowledge in the way foobar2000 handles cue sheets.  This doesn't mean that there is no room for improvement.  I don't think anyone would complain if foobar were to extract the pregap out as a separate file when splitting.  When  converting images, I'm not sure of the best route to take.


Why are you attacking the messenger? Foobar has now proven itself, on two separate instances, to produce files with errors; first, excessive seektables in converted FLACs, and now missing pregaps. Why exactly would I continue using a program like this, especially when it doesn't change for the better? Actually, in the way the program handles this problem it has apparently regressed (and I also feel the way it handles ID3 tags is worse now than in earlier versions, but that's a separate issue).

It's not like understanding cue sheets or the way that Foobar processes them is particularly difficult. Greynol, don't get me wrong, I have respect for you, but you sometimes seem to attack people with legitimate criticisms. But what can you do... the Foobar team doesn't seem particularly robust in addressing issues, so I will just vote with my feet and avoid using it, except for basic playback.

Foobar skips first track pregap when decoding

Reply #20 –
I can't address the seek tables, but when it comes to dealing with 00 indices, foobar2000 works just as it was intended.  This is a matter of fact; there is no reason to get defensive.

>you sometimes seem to attack people with legitimate criticisms.
Considering the way you're attacking foobar2000 and its team, I'd check myself if I were you.

Foobar skips first track pregap when decoding

Reply #21 –
I have to add this, too: For Playback and for a basic Library of
archived audio it´s a real nice tool.
And I keep reccomending it to anyone I know (who is not into
really archiving).

But, taken all its useful additional functions into consideration,
I´d love to see some improvements. Especially regarding
the handling of cuesheets. It should be possible to playback
a flacimage with correct cuesheet as if the original data was inserted.

I don´t know any software which contains exactly this feature,
but hey, we are talking about noone else then f2k itself..

Quote from: greynol on
I can't address the seek tables, but when it comes to dealing with 00 indices, foobar2000 works just as it was intended.  This is a matter of fact; there is no reason to get defensive.


What do you mean by "as it was intended"?

This an excerpt from the CD cuesheet I ripped:

REM DISCNUMBER 1
REM TOTALDISCS 1
REM GENRE Other
REM DATE 2006
REM DISCID 970FE20A
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Damien Rice"
TITLE "9"
FILE "Damien Rice - 9.flac" WAVE
  TRACK 01 AUDIO
    TITLE "9 Crimes"
    PERFORMER "Damien Rice"
    INDEX 00 00:00:00
    INDEX 01 03:33:00

If I play this, there´s no option for me to rewind to 00:00:00 to listen
to that track at INDEX 0.

Does this happen because of the embedded cuesheet?

Foobar skips first track pregap when decoding

Reply #22 –
So are you suggesting that foobar2000 allow you to rewind from the beginning in order to play the hidden track?

This most closely mimics the way an image would behave if it were still a CD.

EDIT:
Those two lines were written before you added to your post beginning with your quote of me, but it's clear that we're on the same page.

To answer your question, yes, this is the result of using the sheet (whether embedded or external).

Again, I think there is room for improvement.

Foobar skips first track pregap when decoding

Reply #23 –
First thanks for your very fast reply..

I checked the embedded cuesheet and it seems to be quite the same
as the original before flacencoding, except that "performer" is
missing.

The indices are all the same, even index 0 of track 1.

So it´s just the way f2k handles it.

So keep up the good work, guys, we have a feature request.