#1 FLAC 1.0.3

closed-out-of-date
None
6
2003-03-21
2002-09-30
Anonymous
No

Hi,
thank you for the very quick port of FLAC!
I have downloaded and tested your Amiga compile of
FLAC. Unfortunately there seems to be a serious problem
with the encoding / decoding routines somehow not
working correctly. See below for details.
(tested with 16bit stereo 44100 Hz WAV files)

-FLAC runs without crash on my A1200 (68030+882, OS
3.1, ixemul.library 48.0)
-FLAC encodes and decodes files without displaying any
error messages

-problem #1:
FLAC needs quite a lot of memory for operation. I've
read that the latest release (1.0.4) has been optimized
for lower memory consumption, could you compile that
version for Amiga, please?

-problem #2:
flac files encoded and decoded on Amiga appear to be OK
(they sound fine), but they are not bit-identical to
the original input file. this is of course a very bad
thing for a LOSSLESS audio codec.

-problem #3:
flac files cannot be exchenged with the Windows version
of the flac software. for instance, when decoding an
Amiga-encoded flac-file on a Windows machine the output
is just noise. it's the same problem the other way
around (Windows flac-file decoded on Amiga).

IMO the problems #2 and #3 are critical, because it
means that the Amiga version of FLAC is NOT a LOSSLESS
audio codec! The interesting thing about that is that
both encoding and decoding does not display any error
essages (corrupted file or something similar), it seems
that the checksum routines don't even realize that
something is going wrong! Quite strange, but i hope you
can get it working.

And about the player: my plan is to write a FLAC player
for Amiga equipped with a Delfina DSP sound board. The
DSP chip will do the decoding and playback, very
similar to the MPEG audio player I wrote a while ago:
http://ftp.uni-paderborn.de/aminetbin/find?delfina

best regards,
Michael Henke

Discussion

  • Diego Casorran
    Diego Casorran
    2002-09-30

    Logged In: YES
    user_id=358695

    hello,
    thx to you that I know it :)
    Flac was more easy to "port" because I do not need modify his source... ^_^

    well,

    #1: you can download now the latest beta

    #2: try the 1.0.4... and give me more time for do things...

    #3: I dont have a pc to try it. but I suppose is a faul by the fucking-win ;D
    if someone can test this under the Linux or MacOS versions (and happens the same) then I consider it a serious problem...

    I m glad you have in mind do a player, but remember the paula users... ;-)

    regards

     
  • Diego Casorran
    Diego Casorran
    2002-09-30

    • priority: 5 --> 6
    • assigned_to: nobody --> diegocr
     
  • Josh Coalson
    Josh Coalson
    2002-09-30

    Logged In: YES
    user_id=78173

    Hi, I'm the FLAC developer, with some comments:

    #1. Yes 1.0.4 should require much less memory.

    #2. Are you encoding WAVE files or raw input? FLAC stores only the "data" and "fmt" subchunks of WAVE files, so if you encode a WAVE file with an unsupported subchunk, then decode the FLAC file to WAVE again, they will not be identical even though the audio is.

    #3. This sounds like an endian related problem. Examine the test on line 951 of src/flac/encode.c to make sure it is correct for your system. Also, what C compiler are you using?

    Josh

     
  • Diego Casorran
    Diego Casorran
    2002-10-03

    Logged In: YES
    user_id=358695

    Hi Josh,

    The check at encode.c seems are Ok for AmigaOS, is big endian too,,
    Im use gcc v2.95.3

    hey Michael, what about the v1.0.4?

     
  • Logged In: NO

    Hi,

    just finished some more detailed tests with the Amiga
    version of FLAC
    1.0.4_beta. The problems first discovered with the 1.0.3
    Amiga compile
    are still there, nothing has changed. I have also had a
    quick look at the
    sources but couldn't find the bug, yet. Josh, I think it's
    your turn. ;-)

    For the test I used raw PCM files (no header) and the
    appropriate command
    lines:

    -5 --endian=little --channels=2 --bps=16 --sample-rate=44100
    --sign=signed le.pcm
    -5 --endian=big --channels=2 --bps=16 --sample-rate=44100
    --sign=signed be.pcm

    -d --force-raw-format --endian=little --sign=signed test.flac
    -d --force-raw-format --endian=big --sign=signed test.flac

    summary:

    Amiga FLAC - little-endian PCM input and output is broken,
    big-endian is ok.
    Win32 FLAC - both little- and big-endian input and output
    are ok.

    results:

    (A) Amiga FLAC encode from little-endian PCM input
    the resulting flac-file...
    -is significantly shorter than the one encoded on Win32.
    (data loss?!)
    -is NOT decoded correctly on Win32 (little- and big-endian
    PCM are noise)

    (B) Amiga FLAC encode from big-endian PCM input
    the resulting flac-file is identical to the one encoded by
    the Win32 version

    (C) Amiga FLAC decode to little-endian PCM output
    -input from (A) (broken FLAC file) - only slightly degraded
    quality
    (the lower 8 bits of the samples seem to be "random noise")
    -input from (B) (correct FLAC file) - completely wrong (loud
    noise)

    (D) Amiga FLAC decode to big-endian PCM output
    -input from (A) (broken FLAC file) - completely wrong (just
    loud noise)
    -input from (B) (correct FLAC file) - output is identical to
    original

    best regards,
    Michael Henke

     
  • Josh Coalson
    Josh Coalson
    2002-10-04

    Logged In: YES
    user_id=78173

    I can't really get to this right now but I can give some clues:

    First, start with a mono 16bps raw file named 2.raw with only one sample. Any 2 byte file will do as long as the 2 bytes are not equal. Try encoding this file as little-endian on the Amiga in gdb, with a break set on the format_input() function in src/flac/encode.c:

    gdb flac
    (gdb) break main
    ...
    (gdb) run --endian=little --channels=2 --bps=16 --sample-rate=44100
    --sign=signed 2.raw
    ...
    (gdb) break format_input
    ...
    (gdb) continue

    Step through to the bps==16 case; if you inspect ucbuffer_[0] and ucbuffer_[1] you will see the bytes of the input file.

    The first 'if' statement in the bps==16 block converts the buffer to host order.

    The second 'if' statement uses the casted ssbuffer to load the values.

    My guess is that one of these two is going wrong. As you step through the debugger you should be able to see where the number coming out is not what you expect. i.e. if 2.raw is 0x01 0x00 then the final number should be 1 and not 256.

    Josh

     
  • Diego Casorran
    Diego Casorran
    2003-03-21

    • status: open --> closed-out-of-date