Re: [flac-dev] Disable all checksum verification in flac/metaflac
Hello, thank you for the response, I’ll try compiling later with these lines removed. I’d be in favor of a proper compile-time option for this. > I think providing an API function and flac+metaflac command line option is > going to be confusing and they will probably be misused. A compile time > option might be possible though, libogg provides that too. I don’t see how the option would be misused or be confusing. As I’ve discovered, popular FLAC-compatible tools like ffmpeg (or libavcodec’s FLAC implementation respectively) don’t strictly adhere to the standard here in order to support weirder files, and the FLAC tools themselves already have options to adhere or deviate from the streamable subset, i.e. a particularly simple part of the FLAC format. If the option has a name that cannot be used by accident, and if it’s properly documented that it may lead to mis-syncing, glitchy audio etc., I don’t see the harm in a run-time option. Though I won’t die on this hill, so feel free to ignore me here. Regards and thanks for your help, kleines Filmröllchen Von: Martijn van Beurden Gesendet: Freitag, 30. Juni 2023 07:23 An: Manuel Bertsch Cc: flac-dev@xiph.org Betreff: Re: [flac-dev] Disable all checksum verification in flac/metaflac Hi, Is it possible for you to compile flac/metaflac yourself? Then you'll only need to remove a few lines, namely these 4: https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2118-L2121 and these 7: https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2141-L2147 As you can see these lines are also disabled on fuzzing. I think providing an API function and flac+metaflac command line option is going to be confusing and they will probably be misused. A compile time option might be possible though, libogg provides that too. Kind regards, Martijn van Beurden Op do 29 jun. 2023 22:28 schreef Manuel Bertsch mailto:malu.bert...@gmail.com> >: Hello all, I’m trying to use flac and metaflac as tooling to analyze the generated FLAC files of a new encoder implementation. However, while my own third-party decoder can handle the output just fine, flac, metaflac, and other tools discard the output since the frame checksum (footer CRC-16) is invalid. This is expected, since I have no checksum generation implemented apart from the frame header checksum (all other checksums are written as 0), but it prevents me from making development process without being able to check my outputs against the reference implementation. I looked around and I couldn’t find a way to turn off either tool’s checksum verification. So I’d like to know how one could turn off checksum verification in the tools, and if that’s not currently possible, I’d like to see that as a feature in a future version of flac. (In that case I would also try to disable the checks in code permanently, though my solution is most likely not going to be upstreamable in any capacity.) FYI, the third-party decoder is highly compliant according to the spec test suite, producing identical audio playback on almost all of the files, but it also doesn’t verify or error on any checksums. ffplay and ffmpeg both accept the file and can play and transcode it correctly, although they ignore the sample count in the streaminfo header and will read all frames they can find. The latter leads me to believe that checksums are the actual issue, even though flac reports the generic “Bad Header” and “Lost Sync”. Greetings and thanks in advance, Kleines Filmröllchen ___ flac-dev mailing list flac-dev@xiph.org <mailto:flac-dev@xiph.org> http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Disable all checksum verification in flac/metaflac
Hi, Is it possible for you to compile flac/metaflac yourself? Then you'll only need to remove a few lines, namely these 4: https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2118-L2121 and these 7: https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2141-L2147 As you can see these lines are also disabled on fuzzing. I think providing an API function and flac+metaflac command line option is going to be confusing and they will probably be misused. A compile time option might be possible though, libogg provides that too. Kind regards, Martijn van Beurden Op do 29 jun. 2023 22:28 schreef Manuel Bertsch : > Hello all, > > > > I’m trying to use flac and metaflac as tooling to analyze the generated > FLAC files of a new encoder implementation. However, while my own > third-party decoder can handle the output just fine, flac, metaflac, and > other tools discard the output since the frame checksum (footer CRC-16) is > invalid. This is expected, since I have no checksum generation implemented > apart from the frame header checksum (all other checksums are written as > 0), but it prevents me from making development process without being able > to check my outputs against the reference implementation. I looked around > and I couldn’t find a way to turn off either tool’s checksum verification. > So I’d like to know how one could turn off checksum verification in the > tools, and if that’s not currently possible, I’d like to see that as a > feature in a future version of flac. (In that case I would also try to > disable the checks in code permanently, though my solution is most likely > not going to be upstreamable in any capacity.) > > > > FYI, the third-party decoder is highly compliant according to the spec > test suite, producing identical audio playback on almost all of the files, > but it also doesn’t verify or error on any checksums. ffplay and ffmpeg > both accept the file and can play and transcode it correctly, although they > ignore the sample count in the streaminfo header and will read all frames > they can find. The latter leads me to believe that checksums are the actual > issue, even though flac reports the generic “Bad Header” and “Lost Sync”. > > > > Greetings and thanks in advance, > > > > Kleines Filmröllchen > ___ > flac-dev mailing list > flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Disable all checksum verification in flac/metaflac
Hello all, Im trying to use flac and metaflac as tooling to analyze the generated FLAC files of a new encoder implementation. However, while my own third-party decoder can handle the output just fine, flac, metaflac, and other tools discard the output since the frame checksum (footer CRC-16) is invalid. This is expected, since I have no checksum generation implemented apart from the frame header checksum (all other checksums are written as 0), but it prevents me from making development process without being able to check my outputs against the reference implementation. I looked around and I couldnt find a way to turn off either tools checksum verification. So Id like to know how one could turn off checksum verification in the tools, and if thats not currently possible, Id like to see that as a feature in a future version of flac. (In that case I would also try to disable the checks in code permanently, though my solution is most likely not going to be upstreamable in any capacity.) FYI, the third-party decoder is highly compliant according to the spec test suite, producing identical audio playback on almost all of the files, but it also doesnt verify or error on any checksums. ffplay and ffmpeg both accept the file and can play and transcode it correctly, although they ignore the sample count in the streaminfo header and will read all frames they can find. The latter leads me to believe that checksums are the actual issue, even though flac reports the generic Bad Header and Lost Sync. Greetings and thanks in advance, Kleines Filmröllchen ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac] metaflac --no-utf8-convert complains about UTF
On Dec 05 20:16:47, h...@stare.cz wrote:
This is 1.3.1 on OpenBSD/amd64.
The --no-utf8-convert option of metaflac(1) does not work for me:
$ metaflac --no-utf8-convert --set-tag=Artist=Žoužlíček aladin.flac
aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8
(You probably can't see the Czech letters properly in my mail,
but that's beside the point.)
Indeed, it is not valid UTF8 (it's LATIN2), but isn't metaflac
supposed to just write it as specified, with this option?
On Dec 06 09:54:55, h...@stare.cz wrote:
The problem seems to be in
src/metaflac/operations_shorthand_vorbiscomment.c
in the set_vc_field() function.
It does check whether utf conversion is required,
/* move 'data' into 'converted', converting to UTF-8 if necessary */
if(raw) {
converted = data;
}
}
but later checks that FLAC__format_vorbiscomment_entry_is_legal()
whether or not we are utf converting; and this function, defined
in ./src/libFLAC/format.c, ultimately calls for utf8len_(s) no matter what.
So my LATIN2 text fails to be legal, because it's not legal UTF
-- which, indeed, it isn't.
On Dec 06 12:33:35, martin.le...@stanfordalumni.org wrote:
METADATA_BLOCK_VORBIS_COMMENT is defined at:
https://xiph.org/flac/format.html#metadata_block_vorbis_comment
and VorbisComments at:
http://www.xiph.org/vorbis/doc/v-comment.html
Note that a VorbisComment is defined as
being UTF-8, although metaflac --no-utf8-convert
doesn't seem to be behaving as advertised.
Reading the above links, the Vorbis Comment is defined to be UTF8.
What is the purpose of --no-utf8-convert in setting tags then?
To specifically ask for invalid files?
Maybe I am misunderstanding the meaning of --no-utf8-convert.
Perhaps the current behaviour is intended, and --no-utf8-convert
just means don't bother converting, it is already UTF8.
Which my example isn't, and metaflac rightfully complains.
Can anybody please shed some light on this?
Finally, Jan might have more luck taking his
problem with metatflac over to the flac-dev list.
On Dec 06 13:55:16, martin.le...@stanfordalumni.org wrote:
Even better, he could submit a bug report at:
http://sourceforge.net/p/flac/bugs/
Yes, I will move this to flac-dev and file a proper bug report
once I am sure it is a bug, and it's the bug I think it is.
BTW, the other Xiph projects track their issues at https://trac.xiph.org/
- is it intentional that FLAC uses the sourceforge bug tracker?
Is there any relation between the two?
Jan
___
Flac mailing list
Flac@xiph.org
http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
Not sure it this is related, but the UTF conversion from and to my local charset does not work for me either (the --no-utf8-convert option is not involved in this). $ export LC_ALL=ISO8859-2 $ metaflac --remove-all-tags file.flac $ metaflac --set-tag=TITLE=Žoužlička file.flac $ metaflac --list --block-number=2 file.flac METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 59 vendor string: reference libFLAC 1.3.0 20130526 comments: 1 comment[0]: TITLE=#ou#li#ka $ metaflac --export-tags-to=- file.flac TITLE=#ou#li#ka Here is how I understand this: metaflac understood the characters in --set-tag=TITLE=Žoužlička, because it knows my local charset is ISO8859-2; metaflac converted that string into UTF8 and stored it in the Vorbis comment; that's what --list shows me. But when I --export the tags, metaflac does _not_ convert the UTF8 comment back to my ISO8859-2 charset. Jan ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
Jan Stary wrote: ... BTW, the other Xiph projects track their issues at https://trac.xiph.org/ - is it intentional that FLAC uses the sourceforge bug tracker? Is there any relation between the two? The only ticket I see at trac.xiph.org specifically for FLAC is dated 2005. However, the code maintainers all hang out on the flac-dev list, so ask there. I suggested SourceForge.net because that is the Bug Tracker link on the Web page at: https://xiph.org/flac/developers.html Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/ ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
On Dec 05 20:16:47, h...@stare.cz wrote:
This is 1.3.1 on OpenBSD/amd64.
The --no-utf8-convert option of metaflac(1) does not work for me:
$ metaflac --no-utf8-convert --set-tag=Artist=Žoužlíček aladin.flac
aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8
(You probably can't see the Czech letters properly in my mail,
but that's beside the point.)
Indeed, it is not valid UTF8 (it's LATIN2), but isn't metaflac
supposed to just write it as specified, with this option?
The problem seems to be in
src/metaflac/operations_shorthand_vorbiscomment.c
in the set_vc_field() function.
It does check whether utf conversion is required,
/* move 'data' into 'converted', converting to UTF-8 if necessary */
if(raw) {
converted = data;
}
}
but later checks that FLAC__format_vorbiscomment_entry_is_legal()
whether or not we are utf converting; and this function, defined
in ./src/libFLAC/format.c, ultimately calls for utf8len_(s) no matter what.
So my LATIN2 text fails to be legal, because it's not legal UTF
-- which, indeed, it isn't.
Jan
___
Flac mailing list
Flac@xiph.org
http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
On Dec 6, 2014, at 12:54 AM, Jan Stary h...@stare.cz wrote:
On Dec 05 20:16:47, h...@stare.cz wrote:
This is 1.3.1 on OpenBSD/amd64.
The --no-utf8-convert option of metaflac(1) does not work for me:
$ metaflac --no-utf8-convert --set-tag=Artist=Žoužlíček aladin.flac
aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8
(You probably can't see the Czech letters properly in my mail,
but that's beside the point.)
Indeed, it is not valid UTF8 (it's LATIN2), but isn't metaflac
supposed to just write it as specified, with this option?
The problem seems to be in
src/metaflac/operations_shorthand_vorbiscomment.c
in the set_vc_field() function.
It does check whether utf conversion is required,
/* move 'data' into 'converted', converting to UTF-8 if necessary */
if(raw) {
converted = data;
}
}
but later checks that FLAC__format_vorbiscomment_entry_is_legal()
whether or not we are utf converting; and this function, defined
in ./src/libFLAC/format.c, ultimately calls for utf8len_(s) no matter what.
So my LATIN2 text fails to be legal, because it's not legal UTF
-- which, indeed, it isn't.
Looks like you found the problem. One piece of code is doing the right thing,
another piece of code is ignoring the option.
By the way, I've never used FLAC inside Ogg Vorbis. Instead, I use pure FLAC
format files. Is there any difference between the way this option works on a
straight FLAC file versus how it works on FLAC data in an Ogg Vorbis container?
Brian
___
Flac mailing list
Flac@xiph.org
http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
Brian Willoughby wrote: Jan Stary wrote: This is 1.3.1 on OpenBSD/amd64. The --no-utf8-convert option of metaflac(1) does not work for me: ... The problem seems to be in src/metaflac/operations_shorthand_vorbiscomment.c in the set_vc_field() function. By the way, I've never used FLAC inside Ogg Vorbis. Instead, I use pure FLAC format files. Is there any difference between the way this option works on a straight FLAC file versus how it works on FLAC data in an Ogg Vorbis container? Some confusion seems to be creeping in, here. Jan's problem, as I understand it, is with the METADATA_BLOCK_VORBIS_COMMENT in a Native FLAC file. (No OggFLAC, Ogg being the container, and no Vorbis, a lossy codec.) METADATA_BLOCK_VORBIS_COMMENT is defined at: https://xiph.org/flac/format.html#metadata_block_vorbis_comment and VorbisComments at: http://www.xiph.org/vorbis/doc/v-comment.html Note that a VorbisComment is defined as being UTF-8, although metaflac --no-utf8-convert doesn't seem to be behaving as advertised. Finally, Jan might have more luck taking his problem with metatflac over to the flac-dev list. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/ ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
Martin Leese wrote: ... Finally, Jan might have more luck taking his problem with metatflac over to the flac-dev list. Even better, he could submit a bug report at: http://sourceforge.net/p/flac/bugs/ Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/ ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
[Flac] metaflac --no-utf8-convert complains about UTF
This is 1.3.1 on OpenBSD/amd64. The --no-utf8-convert option of metaflac(1) does not work for me: $ metaflac --no-utf8-convert --set-tag=Artist=Žoužlíček aladin.flac aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8 (You probably can't see the Czech letters properly in my mail, but that's beside the point.) Indeed, it is not valid UTF8 (it's LATIN2), but isn't metaflac supposed to just write it as specified, with this option? Jan ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac --no-utf8-convert complains about UTF
Hello Jan, I assume the problem is that metaflac has no way of knowing the encoding that was provided on the command line, since it could literally be anything. The --no-utf8-convert option means that metaflac does nothing to the letters as they pass through, and then the problem becomes that the next program to read the tags has to assume the character set without any information. If the program reading the tags gets the character set wrong, then you see garbage. It's possible that the local charset or locale will be the same on the command line and in the application interpreting the characters, but that's not always true. Or, to put it another way, isn't the assumption that all tags in a FLAC file are UTF-8? Thus, if you provide LATIN2 and don't allow metaflac to convert, then it's sure to be garbage. By the way, I can see the Czech letters properly in your email, because it has a header saying Content-Type: text/plain; charset=iso-8859-2 and my Mac uses that information to decode the characters correctly. Not that I can pronounce Czech properly, but it sure looks like some of my favorite movie titles… I'm just guessing here, but I assume that the best way to handle this would be to provide the characters to metaflac in UTF-8 and not use that option (because it ignores the charset). Then the applications reading out the tags will know that they're UTF-8. Obviously, if anyone has better procedures for this, please explain. I don't actually know whether this option is supposed to work on input, output, or both. Brian On Dec 5, 2014, at 11:16 AM, Jan Stary h...@stare.cz wrote: This is 1.3.1 on OpenBSD/amd64. The --no-utf8-convert option of metaflac(1) does not work for me: $ metaflac --no-utf8-convert --set-tag=Artist=Žoužlíček aladin.flac aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8 (You probably can't see the Czech letters properly in my mail, but that's beside the point.) Indeed, it is not valid UTF8 (it's LATIN2), but isn't metaflac supposed to just write it as specified, with this option? ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
[Flac] metaflac: copying all metadata from one FLAC file to another?
I'm trying to copy all of the metadata in a FLAC file to another FLAC file. Is there a simple way to do this with metaflac (perhaps a dump of all the source file's metadata which can be piped to another metaflac for writing into a destination FLAC file)? Currently I'm guessing I'll have to: - copy tags - copy cuesheet - copy picture (for each metadata block) as separate invocations of metaflac. Does this sound correct? Thanks. ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac: malformed vorbis comment field field contains no '=' character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Josh Coalson @ 04/20/2010 10:04 PM: the problem is that the COMMENT tag has carriage returns in it so the pipe command you are trying won't work, it thinks the new line is a comment in itself. i see. if i export the tags to a file, i can see that the second paragraph of the comment is stored on a new line. where does the problem lie, then? is metaflac not interpreting the tag correctly? is kid3-qt (which was used to create the tags) not writing the tag correctly? are users disallowed from using carriage returns? somewhere else? thanks -BEGIN PGP SIGNATURE- iEYEAREIAAYFAkvzSmEACgkQXhfCJNu98qAdbgCgtRNd7coJvS8NuoP+2GBtUY1D dLwAoNjl9eqw8IiyMFP+kezjNYg3x/r/ =CSTQ -END PGP SIGNATURE- ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac: malformed vorbis comment field field contains no '=' character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Josh Coalson @ 04/20/2010 10:04 PM: the problem is that the COMMENT tag has carriage returns in it so the pipe command you are trying won't work, it thinks the new line is a comment in itself. i see. if i export the tags to a file, i can see that the second paragraph of the comment is stored on a new line. where does the problem lie, then? is metaflac not interpreting the tag correctly? is kid3-qt (which was used to create the tags) not writing the tag correctly? are users disallowed from using carriage returns? somewhere else? thanks -BEGIN PGP SIGNATURE- iEYEAREIAAYFAkvPFf0ACgkQXhfCJNu98qCTVQCgoDFQcmnjkccWdh7YNhHuAZrT hHQAn2t6+dNrIYU4RMOAt3Ys64Oy8/0m =eWj+ -END PGP SIGNATURE- ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac: malformed vorbis comment field field contains no '=' character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Josh Coalson @ 04/19/2010 06:40 PM: I would have to see a file sample to debug it. here you are: http://www.sendspace.com/file/wgn39q sorry for the large size, but it is actually the smallest one on the album that was exhibiting the issue. hopefully you enjoy it... classical japanese music from the edo period. ;) -BEGIN PGP SIGNATURE- iEYEAREIAAYFAkvOZ/4ACgkQXhfCJNu98qAvPgCePriEdMip+9F2j/J2Ij+9FEP9 w6QAnA5fK5CWWA/Ij5wna6km+HiFywQq =1Ra4 -END PGP SIGNATURE- ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
[Flac] metaflac-edit utility and suggestion for metaflac --export-tags option
here is a simple utility I wrote for myself and thought maybe others
on linux/cygwin/unix could find it of use
called metaflac-edit (can change, delete or add new metaflac tags)
also I would like to suggest that --export-tags-to=- be given a
synonym of --show-all-tags
#!/bin/sh
#
# metaflac-edit - META info FLAC EDITor
#
# NOTE: use metaflac-set to just quickly change or add one meta tag
TMPDIR=${TMPDIR:-/var/tmp}
TMPFILE=$TMPDIR/$$.$RANDOM
EDITOR=${EDITOR:-vi}
self=$(basename $0)
files=${*:-*.flac}
for file in $files
do
if [ ! -f $file ]; then
echo $self: $file: no such file 2
continue
fi
echo === $file before $self ===
metaflac --export-tags-to=- $file
metaflac --export-tags-to=$TMPFILE $file
$EDITOR $TMPFILE
exec 3$TMPFILE
read -u3 line
status=$?
while [ $status -eq 0 ]
do
tag=$(echo $line | cut -d= -f1)
val=$(echo $line | cut -d= -f2)
metaflac --remove-tag=$tag $file
metaflac --set-tag=$tag=$val $file
read -u3 line
status=$?
done
echo
echo === $file after $self ===
metaflac --export-tags-to=- $file
done
/bin/rm -f $TMPFILE
___
Flac mailing list
Flac@xiph.org
http://lists.xiph.org/mailman/listinfo/flac
[Flac-dev] flac/metaflac 32/64 Universal OS X builds
I've just finished an Xcode 3.1 project file for flac and metaflac that builds both tools as 32/64 bit universal binaries. If anyone is interested in either the binaries or the project, I'll be happy to share them. Stephen ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac/metaflac 32/64 Universal OS X builds
Stephen F. Booth wrote: I've just finished an Xcode 3.1 project file for flac and metaflac that builds both tools as 32/64 bit universal binaries. If anyone is interested in either the binaries or the project, I'll be happy to share them. The thing that always made me curious is how do you test these universal binaries. I meean automated testing. Josh already has a large test suite, but if you don't run that test suite on all four versions why bother? Sure, you can test the native compile without problems, but how do you test the other three? Its also the three cross-compiled ones which are the most likely to be wrong. Erik -- - Erik de Castro Lopo - Monotheistic religion is a plagiarism of a plagiarism of a hearsay of a hearsay, of an illusion of an illusion, extending all the way back to a fabrication of a few nonevents. -- Christopher Hitchens, author of God is not Great ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac/metaflac 32/64 Universal OS X builds
Brian Willoughby wrote: In my experience, with the gcc compiler, cross-compiling is highly reliable. Your experience doesn't match mine. If your code runs on one processor, then it will run on all. That can easily break down in all sort of places. For instance, I'm the main author of libsndfile and when Apple first announced Intel based machines I started getting weird bug reports about libsndfile on Intel macs. After I spent a bunch of my very valuable time the idiot reporting the issue finally confessed that he was compiling libsndfile as a universal binary on PPC and then seeing bugs on Intel. The result of all this was a FAQ: http://www.mega-nerd.com/libsndfile/FAQ.html#Q018 and me adding code to libsndfile to detect when it was being compiled as a UB and erroring out if it was. For libsndfile, the *only* reliable way to create a 32 bit intel/ ppc UB is: 0) configure for intel 1) make 2) make check 3) configure for powerpc 4) make 5) make check 6) use lipo to glue together the test binaries generated in steps 1) and 4) Feel free to add more steps for 64 bit. Linking and such might be an issue, which you will discover immediately when the first person tries to run what you've built on their system. In the libsndfile case it linked fine, but didn't read or write files correctly. This could easily have resulted in people losing valuable work. It still would be great to run these tests on all four. I have a saying 'untested code is broken code'. In this case that should read 'an untested binary is a broken binary'. Erik -- - Erik de Castro Lopo - I've nothing against OO, I do have something against C++. Its a dogs dinner. Anyone who's (tried) to read Stroustrups book on C++ like I had the misfortune of doing knows that the man is very intelligent but has about as much clarity of thought as Timothy Leary on a bad day. -- NJR in comp.os.linux.development.apps ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac/metaflac 32/64 Universal OS X builds
I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to get Xcode to work, but from your report it seems like there is much more to the problem. From your steps, it seems that it is possible to cross-compile, but only if you build one architecture at a time and then manually lipo them together. If I someday find an easy fix for this, I'll let you know. Then again, Stephen may have figured out the magic incantation for Xcode to make this work as simply as it should. So, tell me, Erik: Can you build for Intel on PPC? Can you build for PPC on Intel? If you're willing to do the manual lipo steps, is that all you need to do to make a UB? ... or do you actually need both an Intel Mac and a PowerPC Mac? Thanks for the report. Brian Willoughby Sound Consulting On May 5, 2008, at 16:38, Erik de Castro Lopo wrote: Brian Willoughby wrote: In my experience, with the gcc compiler, cross-compiling is highly reliable. Your experience doesn't match mine. If your code runs on one processor, then it will run on all. That can easily break down in all sort of places. For instance, I'm the main author of libsndfile and when Apple first announced Intel based machines I started getting weird bug reports about libsndfile on Intel macs. After I spent a bunch of my very valuable time the idiot reporting the issue finally confessed that he was compiling libsndfile as a universal binary on PPC and then seeing bugs on Intel. The result of all this was a FAQ: http://www.mega-nerd.com/libsndfile/FAQ.html#Q018 and me adding code to libsndfile to detect when it was being compiled as a UB and erroring out if it was. For libsndfile, the *only* reliable way to create a 32 bit intel/ ppc UB is: 0) configure for intel 1) make 2) make check 3) configure for powerpc 4) make 5) make check 6) use lipo to glue together the test binaries generated in steps 1) and 4) Feel free to add more steps for 64 bit. Linking and such might be an issue, which you will discover immediately when the first person tries to run what you've built on their system. In the libsndfile case it linked fine, but didn't read or write files correctly. This could easily have resulted in people losing valuable work. It still would be great to run these tests on all four. I have a saying 'untested code is broken code'. In this case that should read 'an untested binary is a broken binary'. Erik ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac/metaflac 32/64 Universal OS X builds
Brian Willoughby wrote: So, tell me, Erik: Can you build for Intel on PPC? Can you build for PPC on Intel? If you're willing to do the manual lipo steps, is that all you need to do to make a UB? ... or do you actually need both an Intel Mac and a PowerPC Mac? I actually don't have access to a Mac machine so I'm really not the best person to ask. I also don't know exactly what people who build UBs are doing. I know what went wrong and put obstacles in place so that the same problem would not happen again. Erik -- - Erik de Castro Lopo - We must not forget that Allah's rules have to be established in all lands. -- Imam Muzammil H. Siddiqi of the Islamic Society of North America ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac/metaflac 32/64 Universal OS X builds
From your steps, it seems that it is possible to cross-compile, but only if you build one architecture at a time and then manually lipo them together. If I someday find an easy fix for this, I'll let you know. Then again, Stephen may have figured out the magic incantation for Xcode to make this work as simply as it should. I always have difficulty getting cross-compiling to work from the command line as well. It seems that setting --host, --build, and -- target don't cause the correct compiler to get picked up automatically as I feel they should (and the configure/autoconf docs state). For example, the following should let me cross-compile for PowerPC on my i686 Mac: % ./configure --disable-shared --disable-asm-optimizations --disable- ogg --host=ppc-apple-darwin9 --target=powerpc-apple-darwin9 -- build=i686-apple-darwin9 But the reality is that configure can't find the powerpc compiler, as on my system I have two gcc versions: powerpc-apple-darwin9-gcc-4.0.1 and powerpc-apple-darwin9-gcc-4.2.1. configure only looks for powerpc- apple-darwin9-gcc and variants, and it ends up using plain gcc which obviously isn't a cross compiler. Setting the CC environment variable manually does get things working: % CC=powerpc-apple-darwin9-gcc-4.0.1 ./configure --disable-shared -- disable-asm-optimizations --disable-ogg --host=ppc-apple-darwin9 -- target=powerpc-apple-darwin9 --build=i686-apple-darwin9 Of course, that doesn't take care of PPC64. So rather than repeat this process for all four architectures, I just created one Xcode project with targets for everything I needed, and architectures set appropriately for Release and Debug builds. I suppose one could take the alternate tack and just write a bash script to automate the generation of each architecture and then lipo that output together. So, tell me, Erik: Can you build for Intel on PPC? Can you build for PPC on Intel? If you're willing to do the manual lipo steps, is that all you need to do to make a UB? ... or do you actually need both an Intel Mac and a PowerPC Mac? I have also run into similar issues as the one Erik reports. Invariably it seems to come down to the WORDS_BIGENDIAN macro. I typically settle this problem by hand editing an automatically- generated config.h with the following: #if __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif thus the same config.h (on OS X) will work for any architecture. Anyhow, this is getting extremely off-topic for the list so I apologize. Stephen PS The amusing thing to me about all of this is that the gcc Apple ships is itself cross-compiled: % gcc -v -help Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5480~3/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=powerpc-apple-darwin9 --with-arch=apple --with- tune=generic --program-prefix= --host=i686-apple-darwin9 --target=i686- apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5480) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac] metaflac --remove-all-tags
You might have id3 tags attached to these files. You can check with id3v2 -l and get rid of all id3 tags with id3v2 -D Nicolas there something fishy going on, have about 21 flac files, in a folder, and 9 of them still showing meta tag data in juk. When running metaflac --list, show nothing on all 21 files, however in amarok and juk I can still see some info on 9 flac files. Howdoes one fix these flac files? are they corrupted? flac -t came back ok on all Anyone ? Richard ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac
--- Christopher Brown [EMAIL PROTECTED] wrote: Hi List, I am writing an audio player that exclusively plays FLAC sound files, with CUE sheets. It is written in Python, so it is cross-platform, and it is working very well so far. The soundfile IO is handled by the Audiere library. For metadata (aside from the CUE sheet), I make system calls to metaflac to do things like extract album art for display, and I have a question concerning metaflac. Is there a way to check for the existence of a tag before retrieving it? When I try to get an image from a FLAC file, if it does not exist, FLAC returns an error. This is really not a big deal, because my program runs fine through the error, but it does show up in my programs output, and anyway it seems like the more proper way to do it is to first check to see if the tag is present before retrieving it. Not really a big deal, I just wanted to know if I overlooked something, because I don't see how to do it. not sure I understand... is the image in a tag? if you do metaflac --show-tag=TAG and TAG does not exist, metaflac prints nothing and the exit code is 0. if it does, it prints the matching tags and the exit code is 0. so how are you getting the error? images are now supposed to be stored in the dedicated PICTURE block and that should be accessed via libFLAC http://flac.sourceforge.net/format.html#metadata_block_picture http://flac.sourceforge.net/api/group__flac__metadata__level0.html#ga3 you can check for the existence of a PICTURE block with metaflac --list |grep ... or with libFLAC using the metadata iterators. Josh Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
Re: [Flac] metaflac
i put this in a script and called it metaflac-showall since that was more intuitive to me, but here is how to dump all tags and then you can check the output for the specific one you want: metaflac --export-tags-to=- but i guess that returns more info than you want (the tag names and their values) On 7/16/07, Christopher Brown [EMAIL PROTECTED] wrote: I am writing an audio player that exclusively plays FLAC sound files, with CUE sheets. It is written in Python, so it is cross-platform, and it is working very well so far. The soundfile IO is handled by the Audiere library. For metadata (aside from the CUE sheet), I make system calls to metaflac to do things like extract album art for display, and I have a question concerning metaflac. Is there a way to check for the existence of a tag before retrieving it? When I try to get an image from a FLAC file, if it does not exist, FLAC returns an error. This is really not a big deal, because my program runs fine through the error, but it does show up in my programs output, and anyway it seems like the more proper way to do it is to first check to see if the tag is present before retrieving it. Not really a big deal, I just wanted to know if I overlooked something, because I don't see how to do it. ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
[Flac] metaflac
Hi List, I am writing an audio player that exclusively plays FLAC sound files, with CUE sheets. It is written in Python, so it is cross-platform, and it is working very well so far. The soundfile IO is handled by the Audiere library. For metadata (aside from the CUE sheet), I make system calls to metaflac to do things like extract album art for display, and I have a question concerning metaflac. Is there a way to check for the existence of a tag before retrieving it? When I try to get an image from a FLAC file, if it does not exist, FLAC returns an error. This is really not a big deal, because my program runs fine through the error, but it does show up in my programs output, and anyway it seems like the more proper way to do it is to first check to see if the tag is present before retrieving it. Not really a big deal, I just wanted to know if I overlooked something, because I don't see how to do it. -- Chris ___ Flac mailing list Flac@xiph.org http://lists.xiph.org/mailman/listinfo/flac
[Flac] metaflac Help
Hello FLAC fans, I was wondering if anyone had any suggestions for tagging a large volume of FLAC's (in Windows) without filling them out by hand. I know metaflac can do stuff like this. Can someone help me with the syntax to do this? For example, I tried: = E:\Music\Foldermetaflac --import-tags-from=E:\Music\tag.txt *.flac *.flac: ERROR: reading metadata, status = FLAC__METADATA_CHAIN_STATUS_ERROR_OPENING_FILE The FLAC file could not be opened. Most likely the file does not exist or is not readable. = It seems that I can't use *.flac to pick up all the files in the folder. Any suggestions so I don't have to run this command once per file? Thanks, - Brad ___ Flac mailing list [EMAIL PROTECTED] http://lists.xiph.org/mailman/listinfo/flac
