Help - Search - Members - Calendar
Full Version: FLAC re-encoding
Hydrogenaudio Forums > Lossless Audio Compression > FLAC
Pages: 1, 2, 3, 4, 5, 6
philaphonic
Thank you.
philaphonic
One issue I have noted with this batch file is that occasionally I'll try to process some FLAC that gives me an error about not being a WAV file... and how I need to enter a flag to process it. The batch craps out. I know FLAC is more than just a compressed WAV, but I am not any more knowledgeable. Any way you know of to quickly find such non-WAV-based FLAC files in my library?
Teknojnky
Any have ideas what this is and how to fix it?

CODE
state = FLAC__STREAM_DECODER_READ_FRAME

Synthetic Soul
QUOTE(philaphonic @ Jan 9 2007, 22:17) *
One issue I have noted with this batch file is that occasionally I'll try to process some FLAC that gives me an error about not being a WAV file... and how I need to enter a flag to process it. The batch craps out. I know FLAC is more than just a compressed WAV, but I am not any more knowledgeable. Any way you know of to quickly find such non-WAV-based FLAC files in my library?
Are you talking about the message reported in post #31? By "crap out" do you mean that the batch file terminates immediately? This response from FLAC shouldn't cause the batch file to terminate. Perhaps you could post more info?

The easiest way to simply look for files that fail testing is to navigate to your root FLAC folder and use the command:

CODE
FOR /R %G IN (*.flac) DO (FLAC -t "%G" || ECHO "%G">>failed.txt)

This will create a text file called failed.txt in the same folder with the path of any files that failed testing.

Edit: Actually, if this is the same issue as post #31 then a test won't find them. The re-encoding stage highlights these files. You could try running the following command in the root FLAC folder:

CODE
FOR /R %G IN (*.flac) DO (FLAC -f -o tmp.flac "%G" || ECHO "%G">>failed.txt) & DEL tmp.flac

This will re-encode all files to a file called "tmp.flac", and if an error occurs write the file in question to failed.txt (and finally delete "tmp.flac").

QUOTE(Teknojnky @ Jan 10 2007, 06:13) *
Any have ideas what this is and how to fix it?

CODE
state = FLAC__STREAM_DECODER_READ_FRAME
When do you receive this message? Are you running my batch file, and if so: is it during the test phase, and does it result in the file not being encoded?
Synthetic Soul
2.2.1. Added two new variables.

Set retainListOfFailedFiles to 1 if you want to keep the list of files that failed (flac-113-failed.txt will be created in the same folder as the batch file).

Set retainListOfProcessedFiles to 1 if you want to keep the list of files that were processed by the script (flac-113-processed.txt will be created in the same folder as the batch file).

Both will delete any file of the same name before processing starts, so if you plan to run this on a folder, and then run it again, and want to keep past logs, please move or rename them after the first process.

CODE
REM ######################################################
SET pathToFLAC="C:\My\Path\To\FLAC.EXE"
SET flacOptions=-8 -A "tukey(0.5)" -A flattop
SET retainListOfFailedFiles=1
SET retainListOfProcessedFiles=0
REM ######################################################

Teknojnky
QUOTE(Synthetic Soul @ Jan 10 2007, 02:47) *
QUOTE(Teknojnky @ Jan 10 2007, 06:13) *
Any have ideas what this is and how to fix it?

CODE
state = FLAC__STREAM_DECODER_READ_FRAME
When do you receive this message? Are you running my batch file, and if so: is it during the test phase, and does it result in the file not being encoded?


yes it was with your batch file (2.2), I believe it happened during the 'test' and the file was skipped. It's currently still processsing (I fed it my entire music folder after testing it several times on various folders/files).

Once it finishes I'll try again to get the exact text (I happened to saw which files it was), and I'll also try your updated version.

Cheers
collector
QUOTE(philaphonic @ Jan 9 2007, 14:17) *

One issue I have noted with this batch file is that occasionally I'll try to process some FLAC that gives me an error about not being a WAV file... and how I need to enter a flag to process it. The batch craps out.

Same happened here yesterday while 're-flac-ing' with my own batchfile.
I use "glob.exe -c flac.exe -6 --force --delete-input-file -V *.flac" which works well most of the time.
Action didn't damage the faulty flac's
While viewing the problem files with an hex-editor, I noticed these begin with ID3 not fLaC
Didn't make the flacs myself but got them from the net.. Some are v1.1.0 and some are v1.1.2
After decoding them manually to wav they could be encoded to flac v1.1.3

Remark. For this encoding I sometimes use the Flac frontend v1.7 by speek which uses Tag by Case.
The newly compiled version 2.0.48 also annoyingly writes Db instead of dB. In an earlier version of tag.exe I managed to change that but in the latest version I failed.
So, Synthetic Soul can you change this before compiling it again in the future someday ?
philaphonic
I don't have the files handy anymore as I have since converted them to WavPack, then back to FLAC, to get rid of the problem. A test of the files reveals no problem, yet the batch file pops up some message about needing to reprocess based on a revised input flag. I remember some error verbiage about "--endian" and that FLAC.exe thought the files weren't WAVs, which I think they were.

I had previously used FLACTester to check out these files, and all of them passed.

I will find one of the files again on the Net and post a download site (here) for it soon for you to check out a sample of these problematic FLACs.

Thank you.
Synthetic Soul
QUOTE(Teknojnky @ Jan 10 2007, 13:51) *
yes it was with your batch file (2.2), I believe it happened during the 'test' and the file was skipped. It's currently still processsing (I fed it my entire music folder after testing it several times on various folders/files).

Once it finishes I'll try again to get the exact text (I happened to saw which files it was), and I'll also try your updated version.
Hmm. Unfortunately it sounds like the file is slightly corrupt. You may have to use --decode-through-errors when decoding this file in order to reclaim it. Josh, or a more proficient FLAC user, may be able to deny or add to this. NB: Once the script has finished it should list any files that failed (the major (only?) benefit of this batch file over a one line solution!).

QUOTE(collector @ Jan 10 2007, 14:01) *
Remark. For this encoding I sometimes use the Flac frontend v1.7 by speek which uses Tag by Case.
The newly compiled version 2.0.48 also annoyingly writes Db instead of dB. In an earlier version of tag.exe I managed to change that but in the latest version I failed.
So, Synthetic Soul can you change this before compiling it again in the future someday ?
I haven't changed the setup for compiling Tag, so if you could compile it before you should be able to compile it now. That said, I can look into changing "Db" to "dB"... if I can find where the change needs to be made. smile.gif NB: Latest is 2.0.49 (TAK support added).

QUOTE(philaphonic @ Jan 10 2007, 14:14) *
I don't have the files handy anymore as I have since converted them to WavPack, then back to FLAC, to get rid of the problem. A test of the files reveals no problem, yet the batch file pops up some message about needing to reprocess based on a revised input flag. I remember some error verbiage about "Indian" and that FLAC.exe thought the files weren't WAVs, which I think they were.
QUOTE('Post #31')
flac 1.1.3, Copyright © 2000,2001,2002,2003,2004,2005,2006 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.

WARNING: E:\MP3\Depeche Mode\Playing The Angel\Depeche Mode - Damaged People.fla
c is not a WAVE file; treating as a raw file
ERROR: for encoding a raw file you must specify a value for --endian, --sign, --
channels, --bps, and --sample-rate
Type "flac" for a usage summary or "flac --help" for all options
In the case above, and in collector's experience, this occurs as the file has ID3v2 tags at the beginning. These files do past the test (-t) as the audio data is fine, but when used as input for encoding FLAC barfs.
Teknojnky
QUOTE
________________________________________________________________________

flac 1.1.3, Copyright © 2000,2001,2002,2003,2004,2005,2006 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.

-wumpscut- - 1997 - Embryodead (back-is-front edition) - 09 - Angel.flac: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC


-wumpscut- - 1997 - Embryodead (back-is-front edition) - 09 - Angel.flac: ERROR while decoding data
state = FLAC__STREAM_DECODER_READ_FRAME

File failed testing.



I'll test the affected files shortly and see if they are playable.

philaphonic
>> In the case above, and in collector's experience, this occurs as the file has ID3v2 tags at the beginning.
>> These files do past the test (-t) as the audio data is fine, but when used as input for encoding FLAC barfs.

Perhaps so. I am still trying to find a file to post.
philaphonic
Thanks for any advice.
Synthetic Soul
Thanks for a sample of your file. The file has ID3v2 tags at the beginning, as suspected. It looks like EAC added them (as one of the tags seems to be "Exact Audio Copy (Secure mode)".

AFAIK FLAC will accommodate ID3v1 at the end of the file, but ID3v2 are totally non-standard.

Edit: I have just tested, and it seems to have worked, but you may do best to test yourself. Tag showed me that your file has ID3v1, ID3v2 and FLAC tags. I used the command:

CODE
TAG.EXE --remove --force FLAC myfile.flac

... and that appears to have successfully removed the ID3 tags and left the FLAC (or copied any ID3 tags to the FLAC tags).

Actually, just remembered that you used WavPack to resolve this... smile.gif Forget me.

Edit 2: On the assumption that the file provided was pre 1.1.3 there is something I should note. After using Tag 2.0.49, which is compiled with libFLAC 1.1.3, the file then presented itself as 1.1.3. I renamed FlacGetV.exe to FlacGetV.exe.bak and dragged the file onto flac-113.bat to get it to re-encode irrespective of vendor string...
philaphonic
I have verified the ID3 tags as well are the issue here. Thanks for your work.

God, wouldn't it be nice just to have a single tagging format for once to have to deal with?
collector
QUOTE(Synthetic Soul @ Jan 10 2007, 07:31) *

The file has ID3v2 tags at the beginning, as suspected.

And I can't get this removed, neither by Tagscanner, Tag&Rename nor Tag

CODE
TAG.EXE --remove --force FLAC myfile.flac

Doesn't remove the id3 tag for me sad.gif I can decode the flac first, and then encode the wav to flac again. That's not the problem. But batchprocessing lots of files was just that easy now that flac113 can use flacs as input. Maybe any future flac.exe can ignore these tags and proceed with flac-to-flac
Synthetic Soul
Strange that it appears to work for me (after running Tag the file provided could be re-encoded using FLAC.EXE). I guess it depends on the tagger used to get the tags on there in the first place. ID3v2 seem to be a pain. sad.gif

With the file that philaphonic provided I was able to remove the ID3v2 tag in a hex editor; I just deleted all the bytes before the "fLaC" header which was easy to find due to the padding in the ID3v2 tag.

The only other option I can think of is Tag's --fromfile switch. That would involve re-encoding to a new file and then using Tag to copy the tags from the old to the new... I've no idea how well that would work in your situation, and whether the --force switch would be required...

Josh will probably have a better idea of how to remove these unwanted bytes. It's frustrating that the audio data is perfectly fine, but you can't get to it!
Teknojnky
Update for me:

The 'error' files would indeed play (in mediamonkey, didn't try anything else) with no apparent errors.

I tried 'cleaning' the tags with MM, and again with metaflac --remove-all and didn't help.

I ended up re-encoding them with mediamonkey flac to flac (1.1.2) and then I was able to successfully use the batch.

I'd recommend anyone having problem files try re-encoding them first with mediamonkey (tools > convert audio format > select FLAC and replace existing or specify an alternate file mask/filename), then run thru batch again.

BTW, From 190ish gigs of FLAC's, this script and 1.1.3 saved me ~2 gigs just from what explorer reported free space before/after. (I forgot to get exact size before starting it)

So thanks to the FLAC dev's and thanks Synthetic Soul for making it super easy to take advantage of re-encoding.
Junon
QUOTE(philaphonic @ Jan 10 2007, 16:51) *
God, wouldn't it be nice just to have a single tagging format for once to have to deal with?


Yup. I really wouldn't mind if the world of audio tagging consisted just of either Vorbis comments or APEv2.

Begone, evil ID3! Begone, naughty ASF/WMA! Ohhhhhm! *breaks into some kind of ritual chant that summons up a greater demon to destroy all kinds of annoying metadata*
pepoluan
QUOTE(Teknojnky @ Jan 10 2007, 23:42) *
So thanks to the FLAC dev's and thanks Synthetic Soul for making it super easy to take advantage of re-encoding.
And don't forget to thank MediaMonkey developers for making a player capable of skipping the ID3v2 tags and play the FLAC's however nonstandard they are! smile.gif

Teknojnky
QUOTE(pepoluan @ Jan 10 2007, 11:56) *

QUOTE(Teknojnky @ Jan 10 2007, 23:42) *
So thanks to the FLAC dev's and thanks Synthetic Soul for making it super easy to take advantage of re-encoding.
And don't forget to thank MediaMonkey developers for making a player capable of skipping the ID3v2 tags and play the FLAC's however nonstandard they are! smile.gif



Always much love for the monkey and it's dev's! cool.gif
collector
QUOTE(Synthetic Soul @ Jan 10 2007, 08:42) *

I was able to remove the ID3v2 tag in a hex editor; I just deleted all the bytes before the "fLaC" header which was easy to find due to the padding in the ID3v2 tag.

I could do so too, but then it's easier for me to decode the file to wav and re-encode again. But, up till flac113 I never transcoded flac-to-flac. The 1.1.0 and 1.1.2 play fine with or without those id3v2 tags.

QUOTE
Josh will probably have a better idea of how to remove these unwanted bytes. It's frustrating that the audio data is perfectly fine, but you can't get to it!

Unwanted when transcoding flac-to-flac that is.

philaphonic
I guess my final suggestion is to transcode problem files to WavPack, then back to FLAC. That strips the ID2 tags and keeps all the good FLAC tags.

I use Foobar 0.9.4.2 to do all this and it works a treat.
gottkaiser
Just use the Programm "Mp3tag" to save your Tag's in the Flac file. It removes ID3-Tags automatically.
agentk7
QUOTE(Synthetic Soul @ Jan 9 2007, 13:02) *

OK, version 2.2.0. smile.gif

If FlacGetV.exe (and libFLAC.dll and libmmd.dll) is in the same directory as the batch file it will be used to check the vendor string, and skip 1.1.3 files.

If FlacGetV.exe is not present it will act as per 2.1.0.

CODE
9 file(s) processed.
8 file(s) skipped (already 1.1.3).
0 file(s) encoded.
1 file(s) returned an error.

Files that failed:

  "C:\Documents and Settings\Neil\Desktop\Media\Depeche Mode - Damaged People.flac" [E]



Hi SS,

The batch file is awesome, very helpful. I noticed it even preserves the original file date which is a big plus in my book. That allows me to track what hardware I used during the original rip.... besides the fact I'm a big date sentimentalist smile.gif

Anyway, about the FlacGetV.exe, if tag.exe was used to create the FLAC tags then it overwrites the Flac version with an older one. This is true if you use the flac113b.exe windows package and the tag.exe version that comes with that. Here is the thread about that problem:
http://www.hydrogenaudio.org/forums/index....showtopic=38232

That problem threw me for a loop when I encountered it after upgrading to Flac 1.1.3. Then I noticed all my old Flac 1.1.2 files encoded using the previous windows package had tags with the Flac 1.1.0 version string as a result of this problem.

I'm pointing this out in case people wonder why they might be seeing unnecessary reencodes. Although after the reencode they would at least have the correct version.

I just thought I'd mention it in case anyone ran into that problem and didn't see the other thread.
Synthetic Soul
QUOTE(agentk7 @ Jan 11 2007, 03:15) *
The batch file is awesome, very helpful. I noticed it even preserves the original file date which is a big plus in my book. That allows me to track what hardware I used during the original rip.... besides the fact I'm a big date sentimentalist
I'm glad it's been of use. I can't take credit for the date preservation, that's an inbuilt FLAC thing. smile.gif

QUOTE(agentk7 @ Jan 11 2007, 03:15) *
Anyway, about the FlacGetV.exe, if tag.exe was used to create the FLAC tags then it overwrites the Flac version with an older one. This is true if you use the flac113b.exe windows package and the tag.exe version that comes with that. Here is the thread about that problem:
http://www.hydrogenaudio.org/forums/index....showtopic=38232

That problem threw me for a loop when I encountered it after upgrading to Flac 1.1.3. Then I noticed all my old Flac 1.1.2 files encoded using the previous windows package had tags with the Flac 1.1.0 version string as a result of this problem.
Yes, I mentioned the opposite end of this a little further up this thread (post #63).

If you use my latest release of Tag, which has been compiled with libFLAC 1.1.3, on a pre-1.1.3 file, it will change the vendor string to 1.1.3. If you then use my batch file with FlacGetV.exe it will skip all those files.

The FLAC package uses Case's last release, 2.0.39, which was built with libFLAC 1.1.0. So, as you say, if you use that to tag your 1.1.3 files the vendor string will be changed to 1.1.0, and my batch file will re-encode them unnecessarily.

I actually rebuilt Tag with libFLAC 1.1.3 because of that thread that you quote (glad to see you were the member who thanked me BTW biggrin.gif). I don't really understand the vendor string, but it seems odd to me that simply tagging a file can change the perceived version of FLAC used to encode the file. If the person that builds the installer continues to ignore my releases, or simply recompile the version 2.0.39 code with the latest libFLAC themselves, then I'm afraid you're stuck with having to overwrite the included version with mine, if you want the vendor string to reflect the encode version.

Thanks for the heads up.
collector
QUOTE(Synthetic Soul @ Jan 10 2007, 23:51) *

If you use my latest release of Tag, which has been compiled with libFLAC 1.1.3, on a pre-1.1.3 file, it will change the vendor string to 1.1.3.

Which is incorrect also, since Tag only changes tags, right ? When checking my flacs I'd get the impression all or many seperately tagged ones are v.113

QUOTE

I don't really understand the vendor string, but it seems odd to me that simply tagging a file can change the perceived version of FLAC used to encode the file.

For me it's the reason to avoid Tag and Tag&Rename, because they get the credits while only adding/changing the tags. Those credits, imho, should go to the encoding flacversion smile.gif Maybe the taggers could be mentioned in a comment string. But that's for Josh to decide.
Synthetic Soul
QUOTE(collector @ Jan 11 2007, 10:04) *
Which is incorrect also, since Tag only changes tags, right ? When checking my flacs I'd get the impression all or many seperately tagged ones are v.113
Yes. Well, not 'incorrect' (see below), but confusing and/or illogical. Sorry, I didn't mean to sound like it was a recommendation, but that it was an equal problem to that mentioned by agentk7.

QUOTE(collector @ Jan 11 2007, 10:04) *
For me it's the reason to avoid Tag and Tag&Rename, because they get the credits while only adding/changing the tags. Those credits, imho, should go to the encoding flacversion smile.gif Maybe the taggers could be mentioned in a comment string. But that's for Josh to decide.
I haven't touched Case's tagging code; however, I very much doubt that either of these apps are purposefully changing the vendor string. I suspect it is libFLAC, used to tag the files, which does. Therefore these apps are not acting 'incorrectly'.

However, as stated above, I do agree that the vendor string changing simply because you add an artist field seems very strange. The idea of a string to distinguish the version of codec used to encode the file is great, but having it change with a simple tag update is bizarre. I can only assume that I misunderstand the purpose of the vendor string.

Edit: Hmm.. that said, using the latest metaflac on a file encoded with 1.1.0 does not change the vendor string, so maybe these apps are doing something wrong to not stop the vendor string being amended... hopefully Josh can shed some light. Edit2: I've just looked at the Tag code (tagwrite.cpp, WriteFLACTag()) and, although I have no idea what is going on, I can't see anywhere where the vendor string is being specified. There may be some method to stop the default behaviour of updating the vendor string that has not been implemented. It would be great is a competent C++ programmer could provide a patch...
collector
QUOTE(Synthetic Soul @ Jan 11 2007, 03:43) *

Well, not 'incorrect' (see below), but confusing and/or illogical.

OK. Incorrect in a way that, without any tags at all, my flacs are still the old streams.

QUOTE
Edit2: I've just looked at the Tag code (tagwrite.cpp, WriteFLACTag()) and, although I have no idea what is going on, I can't see anywhere where the vendor string is being specified. There may be some method to stop the default behaviour of updating the vendor string that has not been implemented.

There are programs that have the 'honour' to be mentioned in the vendor string. Tag and Tag&Rename are some of them. As part of the flac-packet it seems logical to me that metaflac is doing its job allright.
Synthetic Soul
QUOTE(collector @ Jan 11 2007, 17:28) *
There are programs that have the 'honour' to be mentioned in the vendor string. Tag and Tag&Rename are some of them. As part of the flac-packet it seems logical to me that metaflac is doing its job allright.
Yes, but i was testing whether amending the vendor string was actually the norm (metaflac behaviour). As I say, Tag uses FLAC's libFLAC, compiled from the source distributed by Josh. So, is it libFLAC's normal behaviour to change the vendor string? It appears so, given that the Tag code doesn't specifically change the string; inferring that, by using libFLAC, any tagging (or any tagging app) will amend the vendor string.

I don't have enough experience with other taggers to know which use libFLAC and which amend the vendor string, and I don't have enough knowledge to pursue this further.

I suppose we're getting off-topic, but I had hoped that we may resolve something with this... well, not 'we', but someone with more knowledge taking an interest...
jcoalson
what happens with the vendor string depends on how the metadata was edited. the vendor string should always be preserved unless during the process of editing, the whole original VORBIS_COMMENT metadata block is deleted by the app (or if there was none in the first place, more unlikely) and a new one created.

but there may be a bug about that; if you can give me specific info about how it is calling libFLAC I can take a look.

Josh
Synthetic Soul
QUOTE(jcoalson @ Jan 11 2007, 18:39) *
but there may be a bug about that; if you can give me specific info about how it is calling libFLAC I can take a look.
I'm afraid I can't be specific as such, as I don't really understand the code. sad.gif

I have uploaded the cpp file in question, here, and the specific function is below:

CODE
int WriteFLACTag ( const char* filename, FileInfo* Info )
{
const char* Items_OggApe[] = {
"TITLE=", APE_TAG_FIELD_TITLE,
"VERSION=", APE_TAG_FIELD_SUBTITLE,
"ARTIST=", APE_TAG_FIELD_ARTIST,
"ALBUM=", APE_TAG_FIELD_ALBUM,
"TRACKNUMBER=", APE_TAG_FIELD_TRACK,
//"ORGANIZATION=", APE_TAG_FIELD_PUBLISHER,
//"DESCRIPTION=", APE_TAG_FIELD_COMMENT,
"GENRE=", APE_TAG_FIELD_GENRE,
"DATE=", APE_TAG_FIELD_YEAR,
//"LOCATION=", APE_TAG_FIELD_RECORDLOCATION,
//"COPYRIGHT=", APE_TAG_FIELD_COPYRIGHT,
//"ISRC=", APE_TAG_FIELD_ISRC
};

char* item;
char* value;
char* p;
size_t item_len;
size_t i, j;
int tag_written = 0;
int needs_new_block = 1;

struct FLAC__Metadata_SimpleIterator* si;

si = FLAC__metadata_simple_iterator_new ();
if ( !FLAC__metadata_simple_iterator_init ( si, filename, 0, 0 ) ) {
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
if ( !FLAC__metadata_simple_iterator_is_writable ( si ) ) {
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}

do {
FLAC__MetadataType type = FLAC__metadata_simple_iterator_get_block_type ( si );

if ( type == FLAC__METADATA_TYPE_VORBIS_COMMENT || type == FLAC__METADATA_TYPE_PADDING ) {
needs_new_block = 0;
break;
}
} while ( FLAC__metadata_simple_iterator_next ( si ) );

if ( !needs_new_block ) {
FLAC__metadata_simple_iterator_delete ( si );

si = FLAC__metadata_simple_iterator_new ();
if ( !FLAC__metadata_simple_iterator_init ( si, filename, 0, 0 ) ) {
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
if ( !FLAC__metadata_simple_iterator_is_writable ( si ) ) {
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
}

do {
FLAC__MetadataType type = FLAC__metadata_simple_iterator_get_block_type ( si );

// Vorbis comment block or padding block
if ( needs_new_block || (type == FLAC__METADATA_TYPE_VORBIS_COMMENT || type == FLAC__METADATA_TYPE_PADDING) ) {
if ( !tag_written ) {
FLAC__StreamMetadata* data;
FLAC__StreamMetadata_VorbisComment_Entry entry;
size_t comments = 0;

if ( (data = FLAC__metadata_object_new ( FLAC__METADATA_TYPE_VORBIS_COMMENT )) == NULL ) {
fprintf ( Options.output, "Failed to create FLAC metadata block.\n" );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}

for ( i = 0; i < Info->TagItemCount; i++ ) {
if ( Info->TagItems[i].Item[0] != '\0' && Info->TagItems[i].ValueU[0] != '\0' )
comments++;
}

if ( !FLAC__metadata_object_vorbiscomment_resize_comments ( data, comments ) ) {
fprintf ( Options.output, "Failed to create FLAC metadata block.\n" );
FLAC__metadata_object_delete ( data );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}

comments = 0;

for ( i = 0; i < Info->TagItemCount; i++ ) {
int replaced_item = 0;
if ( Info->TagItems[i].Item[0] == '\0' || Info->TagItems[i].ValueU[0] == '\0' )
continue;

for ( j = 0; j < (sizeof (Items_OggApe) / sizeof (*Items_OggApe)) / 2; j++ ) {
if ( stricmp ( (char *)Info->TagItems[i].Item, (char *)Items_OggApe[j*2+1] ) == 0 ) {
replaced_item = 1;
item_len = strlen ((char *)Items_OggApe[j*2]) - 1;
if ( (item = (char *)malloc ( item_len + 1 )) == NULL ) {
fprintf ( Options.output, "WriteFLACTag: Memory allocation failed.\n" );
exit (1);
}
strncpy ( item, Items_OggApe[j*2], item_len );
item[item_len] = '\0';
break;
}
}

if ( !replaced_item ) {
item_len = Info->TagItems[i].ItemSize;
if ( (item = (char *)malloc ( item_len + 1 )) == NULL ) {
fprintf ( Options.output, "WriteFLACTag: Memory allocation failed.\n" );
exit (1);
}
strcpy ( (char *)item, (char *)Info->TagItems[i].Item );
}

p = item;
while ( *p != '\0' ) {
int ch = *p;
if ( ch == '=' || ch < 0x20 || ch > 0x7D ) ch = '_';
*p++ = ch;
}

entry.length = strlen (item) + 1 + Info->TagItems[i].ValueUSize;
if ( (value = (char *)malloc ( entry.length + 1 )) == NULL ) {
fprintf ( Options.output, "WriteFLACTag: Memory allocation failed.\n" );
exit (1);
}
sprintf ( value, "%s=%s", item, Info->TagItems[i].ValueU );
entry.entry = (unsigned char *)value;

if ( !FLAC__metadata_object_vorbiscomment_set_comment ( data, comments++, entry, 1 ) ) {
fprintf ( Options.output, "Failed to create FLAC metadata block.\n" );
FLAC__metadata_object_delete ( data );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}

free ( item );
free ( value );
}

//FLAC__metadata_object_vorbiscomment_set_vendor_string ( data, entry, 1 );
/*
FLAC__metadata_object_vorbiscomment_resize_comments ( FLAC__StreamMetadata *object, unsigned new_num_comments);
FLAC__metadata_object_vorbiscomment_set_comment ( FLAC__StreamMetadata *object, unsigned comment_num, FLAC__StreamMetadata_VorbisComment_Entry entry, FLAC__bool copy);
FLAC__metadata_object_vorbiscomment_insert_comment (FLAC__StreamMetadata *object, unsigned comment_num, FLAC__StreamMetadata_VorbisComment_Entry entry, FLAC__bool copy);
FLAC__metadata_object_vorbiscomment_delete_comment (FLAC__StreamMetadata *object, unsigned comment_num);
*/

if ( !needs_new_block ) {
if ( !FLAC__metadata_simple_iterator_set_block ( si, data, 1 ) ) { // 1 = use padding
fprintf ( Options.output, "Failed to write FLAC metadata block.\n" );
FLAC__metadata_object_delete ( data );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
} else {
if ( !FLAC__metadata_simple_iterator_insert_block_after ( si, data, 1 ) ) { // 1 = use padding
fprintf ( Options.output, "Failed to write FLAC metadata block.\n" );
FLAC__metadata_object_delete ( data );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
}

FLAC__metadata_object_delete ( data );

tag_written = 1;
} else if ( type == FLAC__METADATA_TYPE_VORBIS_COMMENT ) {
if ( !FLAC__metadata_simple_iterator_delete_block ( si, 0 ) ) { // 0 = no padding
fprintf ( Options.output, "Failed to remove FLAC metadata block.\n" );
FLAC__metadata_simple_iterator_delete ( si );
return 1;
}
}
}
} while ( FLAC__metadata_simple_iterator_next ( si ) );

FLAC__metadata_simple_iterator_delete ( si );

fprintf ( Options.output, "FLAC tag written.\n" );

return 0;
}

Unfortunately, if you, or another developer familiar with the FLAC library, are not prepared to look at the code then we're stuck. Perhaps, if you could help resolve this for version 2.0.50, it could be distributed with the FLAC Windows installer, and Windows FLAC users can sleep easy...

That said, I don't expect you to resolve this. I was mainly querying whether this was standard for the library or not. As you say it is not then I must put it down to the specific code and forget about it, until someone with the proper skills takes on the mantle.
jcoalson
ok, I can see in that loop is prepending it's own created VORBIS_COMMENT, then deleting any other it finds afterward. so it will get the vendor string of the current library in the created VORBIS_COMMENT.

2 ways to fix: update existing VORBIS_COMMENT instead of delete and replace, or copy vendor string into new comment.

Josh
Synthetic Soul
Thanks for the confirmation Josh.

If only I knew my arse from my elbow...

biggrin.gif
gottkaiser
@Synthetic Soul

does you'r batch file support future flac versions? I mean if you use FlacGetV.exe.
For example if the flac.exe is for example v1.1.4. Does it just re-encode files lower 1.1.4?
Synthetic Soul
It didn't, but it does now. biggrin.gif Version 2.2.2.

It's a very simple change but to make it easier I have turned it into a variable so the user can set it at the top with all the others.

CODE
REM ######################################################
SET pathToFLAC="FLAC.EXE"
SET flacOptions=-8
SET retainListOfFailedFiles=0
SET retainListOfProcessedFiles=0
SET flacVersion=113
REM ######################################################

Change 113 to 114 to skip files that are 1.1.4.

Of course, the batch file name may be a little confusing... wink.gif
gottkaiser
thanks :-)
JJZolx
I'm running into problems re-encoding a set of Flac files that were encoded using Flac 1.1.1. I can run Flac 1.1.3 using -d and it decodes the file to wav without a problem. Is this a known issue?

Here's the output I get on one of the files when using Flac 1.1.3 to either re-encode or to verify the file. It's dbPowerAMP's Windows Explorer extension that tells me it was encoded by Flac 1.1.1.

CODE
C:\temp\test>flac -f test.flac

flac 1.1.3, Copyright (C) 2000,2001,2002,2003,2004,2005,2006  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

WARNING: test.flac is not a WAVE file; treating as a raw file
ERROR: for encoding a raw file you must specify a value for --endian, --sign, --channels, --bps, and --sample-rate
Type "flac" for a usage summary or "flac --help" for all options


Edit: My bad. I meant to run a test in the second example. The file tests fine, but it won't re-encode.

CODE
C:\temp\test>flac -t test.flac

flac 1.1.3, Copyright (C) 2000,2001,2002,2003,2004,2005,2006  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

test.flac: ok
JJZolx
QUOTE(JJZolx @ Jan 14 2007, 18:14) *

I'm running into problems re-encoding a set of Flac files that were encoded using Flac 1.1.1. I can run Flac 1.1.3 using -d and it decodes the file to wav without a problem. Is this a known issue?

Ok. I went back and read through this entire thread. Looking at the file in a hex editor I can see that it does indeed have an ID3v2.3.0 tag in the beginning.

My only question is - Why is Flac able to decode this file without a hitch, but it not _re_encode it? That doesn't really make sene to me. It means that using this method of re-encoding is of limited use. You need to test the file somehow, then the old method of first decoding to WAV if it fails. May as well just use the older method to be safe until this can be fixed.
Synthetic Soul
Not really. If you have 1000 FLAC files and 2 with ID3v2 tags at the start it's well worth getting 998 converted with tags and then only having to deal with the 2 you know need special attention.

NB: This is not a FLAC issue. FLAC never has supported ID3v2 tags, so should not be expected to deal with files that have them. It is a user/EAC issue.
jcoalson
QUOTE(JJZolx @ Jan 14 2007, 22:17) *
My only question is - Why is Flac able to decode this file without a hitch, but it not _re_encode it? That doesn't really make sene to me.

yeah, the reason for this is that the actual decoder can skip id3v2 if it already knows it's a FLAC file.

but the flac program itself does not yet know for sure the file type. it does not go by just the extension (some platforms do not have it and some users can mess this up believe it or not), so it reads the beginning of the file to try and figure out what it is.

but, in order to support pipes properly it has to buffer all that lookahead because it can't seek the input back to the beginning after figuring out the file. but with id3v2 that could be a lot and you can't really know how long except with multiple reads, so I punt in this case.

there are three possible fixes, but all seem like more than acceptable than to just reject invalid files:

1) add another option like --force-flac-format
2) split the filetype detection code to work for seekable input, then the bug will only be with pipes
3) make the detection code more complicated to buffer the whole id3 tag

in the meantime I've at least fixed the code to notice the id3 tag and give a better error. I guess I could also just trust every input file whose names start with .flac. but this will not fix it on platforms like (I think) BeOS where there is no extension.

Josh
JJZolx
QUOTE(jcoalson @ Jan 15 2007, 09:36) *
but, in order to support pipes properly it has to buffer all that lookahead because it can't seek the input back to the beginning after figuring out the file. but with id3v2 that could be a lot and you can't really know how long except with multiple reads, so I punt in this case.

Thanks Josh. It makes a lot more sense now. Clarifying the error message is a good start and may be sufficient.

I've been able to work around this in my script by first trying the native re-encoding and if Flac throws a non-zero exit code, then I fall back to the old method of decoding first to wav and encoding again, passing all the tags along.

HydroFred
I use the following batch file to convert my old flac files to 1.1.3

CODE

@echo off
pause
for /r %%i in (*.flac) do start /low /wait flac -f -8 -A "tukey(0,5)" "%%i"


But unfortunately, the batch never stops. If for example I run it in a directory with 2 flac files named 1.flac and 2.flac, it will keep alternating between the two. It seems the FOR somehow recognizes that a file has changed and therefor adds it to the list of files to be processed...?

Any way to stop this? If I encode to another file with -o "%%i.new" or something it works perfect, but I see no easy way to delete the old files afterwards and rename all the .flac.new to .flac
Synthetic Soul
Yes, that happened to my early version. As you say, I think XP (it doesn't happen on 2K) dynamically alters the collection of files, seeing the amended file as new.

I resolved this in mine by creating a list of files using that syntax, and then using that list as the source files. You can see my code here.

Edit: Here's a cut-down version:

CODE
FOR /R %%G IN (*.flac) DO ECHO "%%G">>list.txt
FOR /F "tokens=* delims=" %%H IN (list.txt) DO START /LOW /WAIT FLAC.EXE -f -8 -A "tukey(0,5)" %%H
DEL list.txt

gottkaiser
QUOTE(HydroFred @ Jan 16 2007, 15:06) *

I use the following batch file to convert my old flac files to 1.1.3

CODE

@echo off
pause
for /r %%i in (*.flac) do start /low /wait flac -f -8 -A "tukey(0,5)" "%%i"


But unfortunately, the batch never stops. If for example I run it in a directory with 2 flac files named 1.flac and 2.flac, it will keep alternating between the two. It seems the FOR somehow recognizes that a file has changed and therefor adds it to the list of files to be processed...?

Any way to stop this? If I encode to another file with -o "%%i.new" or something it works perfect, but I see no easy way to delete the old files afterwards and rename all the .flac.new to .flac



Wy don't you use this batch file?
It's really helpfull!


Oh someone was faster :-)
HydroFred
Thanks, I'll just use your batch file instead of worrying too much to find my own solution.

I took the liberty of modifying line #12
CODE

SET flacOptions=-8 -A "tukey(0,5)"


Again, thanks for providing the batch file. Works like a charm.
gottkaiser
You could also just use the flac.exe version from http://www.rarewares.org/lossless.html. (You need to copy the libmmd.dll in the "Windows" folder, You find it on the same page)
This is new compile of the official release + the comma bugfix.

Then you don't need -A "tukey(0,5)"
HydroFred
QUOTE(gottkaiser @ Jan 16 2007, 16:12) *

You could also just use the flac.exe version from http://www.rarewares.org/lossless.html.
This is new compile of the official release + the comma bugfix.

"MSVC6 compile"... wow... are people still using that old compiler piece of crap? blink.gif

It does not work however: "Die Anwendung konnte nicht gestartet werden, weil libmmd.dll nicht gefunden wurde. Neuinstallation der Anwendung könnte das Problem beheben."

I'll stay with the official version and the tukey(0,5) tongue.gif

EDIT: Hooray, managed to shrink an 4825 MB directory down to 4770 MB smile.gif
collector
QUOTE(Synthetic Soul @ Jan 10 2007, 07:31) *

The file has ID3v2 tags at the beginning, as suspected. It looks like EAC added them
FLAC will accommodate ID3v1 at the end of the file, but ID3v2 are totally non-standard.

Sorry, for jumping back in time. I don't know if it's an id3version two tag, but tonight I noticed that eac adds that horrible id3tag when I tick [v] add id3 tag at the compression options tab/page.
gottkaiser
@Synthetic Soul

I have another suggestion for the batch file.
You write all the added files in the beginning to the text file for the processed files.
Maybe you could just add them when they are really successful processed. So you could read all processed files. In the case you abort the transcoding in the middle.

And maybe you could include a option to pursue an old log file.


What do you think? :-)
Synthetic Soul
The processed list has to contain all files, as this is the list that is used to detirmine which files to process. However, as well as writing all failed files to a log I could also easily write all successful files to a log (and add another config flag to specify whether it is kept or not).

I'm a little confused by your other request, but two interesting actions spring to mind.

Firstly, and most easily, I could allow the user to drag a log file onto the batch file to start, rather than a file or folder. The script would then use all files in the log as the process list, rather than create it's own. This may be useful to re-process the "flac-113-failed.txt" log, once the user has made some changes to the files (like removing ID3v2 tags).

Secondly, but more difficultly, the script could somehow restart processing a folder and its subfolders, by using the newly suggested "flac-113-successful.txt" and "flac-113-processed.txt" to restart the list, skipping any files that exist in "flac-113-successful.txt". Presumably this would be initiated by dragging "flac-113-processed.txt" onto the batch file, and having "flac-113-successful.txt" exist in the same folder as flac-113.bat. Or something. smile.gif

Anyway, thanks for the ideas. I'll see what I can do. I'm a little busy at the moment. sad.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.