Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
2013/2/10 Erik de Castro Lopo mle...@mega-nerd.com: Johnny Rosenberg wrote: Anyway, if I'm allowed to ask a libsndfile question here, Sorry, but no, this list is for FLAC related discussion. And of course you won't waste your time replying outside this mailing list? Is there a libsndfile mailing list? Hm… yet another stupid question, of course. If there is, you wouldn't want me to know about it, right? :P Kind regards Johnny Rosenberg ジョニー・ローゼンバーグ Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Johnny Rosenberg wrote: And of course you won't waste your time replying outside this mailing list? Is there a libsndfile mailing list? Hm… yet another stupid question, of course. If there is, you wouldn't want me to know about it, right? :P http://lmgtfy.com/?q=libsndfile+mailing+listl=1 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
2013/2/10 Erik de Castro Lopo mle...@mega-nerd.com: Johnny Rosenberg wrote: And of course you won't waste your time replying outside this mailing list? Is there a libsndfile mailing list? Hm… yet another stupid question, of course. If there is, you wouldn't want me to know about it, right? :P http://lmgtfy.com/?q=libsndfile+mailing+listl=1 Oh… thanks for making me feel even more stupid…! :) I'll try to be less annoying on that list, if I decide to subscribe… Johnny Rosenberg (no, I'm not the excellent musician from the Netherlands, I'm just another musician, not so excellent, from another country, sorry) Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
2013/2/8 Erik de Castro Lopo mle...@mega-nerd.com: Collin wrote: It turns out it was an error on my part; sorry for the trouble. I misunderstood the format libflac was expecting my samples in. I found the wording in the documentation very confusing. My audio file has 2 channels and 16-bit samples, so I have to pull out each individual sample, push it into a FLAC__int32, and fix endian-ness before I can pass it to libflac. The documentation made me think that libflac just wanted me to shove my 2-byte sample into a FLAC__int32. I wasn't aware that it wanted me to extend the sign, as well. At some stage it might make sense for us to make the FLAC API a little more user/programmer friendly. Something to match libsndfile's ease of use. That would be great! I was actually starting my small ”project” with libsndfile, but it was done in a way that I didn't agree with, and since I only work with FLAC files (mostly 24 bits) I decided to try to go with libflac instead, which seems to let me do things the way I want more than libsndfile. For example, when loading an audiofile with libsndfile, all the samples are converted to floating point numbers, which is what I want anyway, but the conversion is done by dividing the integers from the file with pow(2,bps-1), but when converting back, they multiply with pow(2,bps-1)-1, so if you just read and then write, you end up with a slightly lower volume (not that you can hear any difference if you do it only a few times, but still, it isn't right, AND it is very easy to do it right, so why don't they?)… Johnny Rosenberg, the beginner Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
2013/2/8 Erik de Castro Lopo mle...@mega-nerd.com: Collin wrote: It turns out it was an error on my part; sorry for the trouble. I misunderstood the format libflac was expecting my samples in. I found the wording in the documentation very confusing. My audio file has 2 channels and 16-bit samples, so I have to pull out each individual sample, push it into a FLAC__int32, and fix endian-ness before I can pass it to libflac. The documentation made me think that libflac just wanted me to shove my 2-byte sample into a FLAC__int32. I wasn't aware that it wanted me to extend the sign, as well. At some stage it might make sense for us to make the FLAC API a little more user/programmer friendly. I seem to recall that the FLAC library requires fixed point numbers that are right-justified in a 32-bit fixed-point 'long int', whereas the standard everywhere else seems to be left-justified. Left- justified makes more sense because it allows 16-bit, 20-bit, 24-bit, 32-bit, and other depths to be more easily converted. It's been a while since I needed to know this level of detail, because I wrote my own ObjC library on top of the C FLAC library since I didn't want to use the C++ FLAC library, and once I solved the justification of the bits I never had to think about it again. However, for new programs being written to use the FLAC libraries, I totally agree that there should be a friendlier interface (assuming I haven't remembered all of this wrong). Note that the old interface should be maintained for compatibility with existing software. The new, friendlier interface can simply use a slightly different (member) function name to access the same objects. There's no reason both can't be supported, or even float as well. Something to match libsndfile's ease of use. I do not use libsndfile, so I wouldn't make this comparison. On Feb 9, 2013, at 03:13, Johnny Rosenberg wrote: That would be great! I was actually starting my small ”project” with libsndfile, but it was done in a way that I didn't agree with, and since I only work with FLAC files (mostly 24 bits) I decided to try to go with libflac instead, which seems to let me do things the way I want more than libsndfile. For example, when loading an audiofile with libsndfile, all the samples are converted to floating point numbers, which is what I want anyway, but the conversion is done by dividing the integers from the file with pow(2,bps-1), but when converting back, they multiply with pow(2,bps-1)-1, so if you just read and then write, you end up with a slightly lower volume (not that you can hear any difference if you do it only a few times, but still, it isn't right, AND it is very easy to do it right, so why don't they?)… Johnny Rosenberg, the beginner For a beginner, you sure have the math right. Lossless conversion should always be handled via a factor with only a single significant digit, otherwise you're actually performing a sum. Multiplying by a factor with a single (binary) significant digit is equivalent to multiplying by 1. pow(2, N) is a valid conversion factor. pow(2, N)-1 is not. Basically, converting a 16-bit sample using pow(2, 15)-1 is the same as summing 15 lossless conversions that happen to be one off from the proper lossless conversion. The 'why' is that libsndfile hopes to solve a problem that doesn't always exist. Namely, that scientific synthesis of data in floating point often ranges from +1 to -1, but the fixed point output format of most sound files does not allow +1 (even though it does allow -1). This is due to the nature of twos-complement fixed-point numbers. I have no idea why libsndfile handles integer input to integer output in this lossy way, but that was a choice made by libsndfile that seems beyond the possibility of correcting. It would have seemed much simpler to require floating point data synthesis to apply the pow(2, N)-1 scaling only as needed, rather than apply it to all audio files (most of which come from fixed-point A/D convertors that don't need any scaling). In other words, libsndfile is really only correctly applicable to a very esoteric set of data which does not include most audio. Regardless of libsndfile's architecture and design, libFLAC should by no means duplicate the incorrect conversion. There especially should not be an asymmetrical set of conversion factors. All of Apple's CoreAudio tools use float without lossy conversion. The only requirement there is that synthesized data should avoid +1.0 sample values unless clipping is acceptable or scaling is added before conversion. Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
2013/2/9 Erik de Castro Lopo mle...@mega-nerd.com: Johnny Rosenberg wrote: For example, when loading an audiofile with libsndfile, all the samples are converted to floating point numbers, With libsndfile, converting to float is optional. You can just as easily read int or short. which is what I want anyway, but the conversion is done by dividing the integers from the file with pow(2,bps-1), but when converting back, they multiply with pow(2,bps-1)-1, so if you just read and then write, you end up with a slightly lower volume (not that you can hear any difference if you do it only a few times, but still, it isn't right, AND it is very easy to do it right, so why don't they?)… Firstly, you do realise that I am the main author and maintainer of libsndfile, don't you? Yes I do, now that you mentioned it. I'm not sure why that matters in a FLAC-dev mailing list, though. I didn't know there was a maintainer anyway these days, since I didn't get a reply when emailing about this a couple of years ago (or maybe it was last year, I don't remember – I sent it from one of my other email addresses, since I use this one for mailing lists only). Secondly, the scaling can be switched off don't you? See: http://www.mega-nerd.com/libsndfile/command.html#SFC_SET_NORM_DOUBLE Thanks, I don't think I saw that page before, for some strange reason. The sentence ”setting normalisation to SF_FALSE means that no scaling will take place”, does this mean, for instance for a 24-bit file, that the values will be doubles in the interval -8388608 to +8388607? That information should probably be added to question 10 in your FAQ, I suppose. For my purpose, not ”normalising” at all seems to be a good enough idea, I think. I will calculate the levels from dB anyway, so I just need to know how many bits per sample there is, which libsndfile easily lets me know. But I will try to do my thing with libflac first. If I fail making my code clean, simple and readable (and working…), I might give libsndfile another try. Finally, there are about 700 different way so convert between int and float. I chose the one that I thought had provided the best trade off. I stand by that decision. Well, the good thing is that this SFC_SET_NORM_DOUBLE thing allows me to do it the 701th way… Maybe I should convert to % or ‰… Anyway, if I'm allowed to ask a libsndfile question here, is there a special reason why you read sound files into one-dimensional arrays instead of two-dimensional ones (such as AudioData[Channel][Sample])? If so, what is that reason? Thanks. Kind regards Johnny Rosenberg ジョニー・ローゼンバーグ Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Whatever enhancements occur for libFLAC, we certainly should not create a situation where some flag gives different results for one set of users versus another. Normalization of data should be separate from conversion of data. libFLAC should only handle conversion of data. If people want a method for normalizing their audio data, then they should use a DAW or at least a library like libsndfile. To avoid bloat, libFLAC should merely handle conversion between FLAC compressed and uncompressed samples. Any potential problems where synthetic float waveform samples might clip during conversion to FLAC should be handled by a separate tool. In other words, the file should be processed before it is compressed. There are industry standards for conversion whereby only exact powers of two are used. Anything else doesn't belong in libFLAC. Namely, pow (2,bps-1)-1 should not be used or allowed anywhere in libFLAC. Brian Willoughby Sound Consulting On Feb 9, 2013, at 12:50, Erik de Castro Lopo wrote: Secondly, the scaling can be switched off don't you? See: http://www.mega-nerd.com/libsndfile/ command.html#SFC_SET_NORM_DOUBLE ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Johnny Rosenberg wrote: Anyway, if I'm allowed to ask a libsndfile question here, Sorry, but no, this list is for FLAC related discussion. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Are you calling FLAC__stream_encoder_finish(encoder); before you call FLAC__stream_encoder_delete(encoder); That would cause this issue. -Ben Allison I'm using libflac on Windows to compress some audio samples. I'm building the library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well formed PCM encoded data. I'm finding some very odd behavior. If I enable verify on the encode stream, I get a verify mismatch on most of my sample sets. Each set of samples returns this error at a different location in the stream, but always the same location for the same file. However, if I disable verify, the resulting FLAC encoded data DOES decode correctly in most cases, giving me an exact replica of the input. In the other cases, one of the frames decodes into wrong data. I have not seen more than one frame for a given set of data decode incorrectly; the frames before and after it are correct. Sometimes the bad frame is partially correct, or has many bytes that are close to the original. The bad frame's data is always the same, no matter how many times I try to re-encode the original file. I've tried encoding and decoding these files with the FLAC command line tool, and it has no problems, so I think there might be an issue with my libflac binaries. Has anyone encountered a similar problem, or are there any known issues that could explain this? ___ 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
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Erik de Castro Lopo mle+la at mega-nerd.com writes: Collin wrote: Has anyone encountered a similar problem, or are there any known issues that could explain this? No known issues of this kind, but I would like to see a repeatable test case so I can investigate further. Cheers, Erik It turns out it was an error on my part; sorry for the trouble. I misunderstood the format libflac was expecting my samples in. I found the wording in the documentation very confusing. My audio file has 2 channels and 16-bit samples, so I have to pull out each individual sample, push it into a FLAC__int32, and fix endian-ness before I can pass it to libflac. The documentation made me think that libflac just wanted me to shove my 2-byte sample into a FLAC__int32. I wasn't aware that it wanted me to extend the sign, as well. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Collin wrote: It turns out it was an error on my part; sorry for the trouble. I misunderstood the format libflac was expecting my samples in. I found the wording in the documentation very confusing. My audio file has 2 channels and 16-bit samples, so I have to pull out each individual sample, push it into a FLAC__int32, and fix endian-ness before I can pass it to libflac. The documentation made me think that libflac just wanted me to shove my 2-byte sample into a FLAC__int32. I wasn't aware that it wanted me to extend the sign, as well. At some stage it might make sense for us to make the FLAC API a little more user/programmer friendly. Something to match libsndfile's ease of use. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
I'm using libflac on Windows to compress some audio samples. I'm building the library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well formed PCM encoded data. I'm finding some very odd behavior. If I enable verify on the encode stream, I get a verify mismatch on most of my sample sets. Each set of samples returns this error at a different location in the stream, but always the same location for the same file. However, if I disable verify, the resulting FLAC encoded data DOES decode correctly in most cases, giving me an exact replica of the input. In the other cases, one of the frames decodes into wrong data. I have not seen more than one frame for a given set of data decode incorrectly; the frames before and after it are correct. Sometimes the bad frame is partially correct, or has many bytes that are close to the original. The bad frame's data is always the same, no matter how many times I try to re-encode the original file. I've tried encoding and decoding these files with the FLAC command line tool, and it has no problems, so I think there might be an issue with my libflac binaries. Has anyone encountered a similar problem, or are there any known issues that could explain this? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
El 07/02/13 19:07, Collin escribió: I'm using libflac on Windows to compress some audio samples. I'm building the library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well formed PCM encoded data. I'm finding some very odd behavior. If I enable verify on the encode stream, I get a verify mismatch on most of my sample sets. Each set of samples returns this error at a different location in the stream, but always the same location for the same file. However, if I disable verify, the resulting FLAC encoded data DOES decode correctly in most cases, giving me an exact replica of the input. Before debugging further, ensure you can reproduce this in a different computer, or verify that you dont have broken RAM. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
Cristian Rodríguez wrote: sample sets. Each set of samples returns this error at a different location in the stream, but always the same location for the same file. or has many bytes that are close to the original. The bad frame's data is always the same, no matter how many times I try to re-encode the original file. Before debugging further, ensure you can reproduce this in a different computer, or verify that you dont have broken RAM. Given that the errors occur at repeatable locations, broken RAM seems unlikely. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
