output matching different between windows and linux. I created a database of filehashes which is around 340MB. When i try to query around 100 mp3 files my output is different between my windows machine and my raspberri pi. The database is identical, the query is identical but the windows machine finds significantly more matches. Both are running python 3.9. Database was created on the windows machine and transfered to the pi. Anyone encountered something similar?

It could be that the mp3 decoder gives a slightly different result on the two architectures. Try converting the query to an afpk file (preprocessed peaks) then run the query on both machines; the results should be the same.

MP3 decoders (even different versions of mpg123) can differ in their net delay, and an identically-timed query will get many more hits than a random time alignment.

DAn.

On Sun, Nov 6, 2022 at 13:06 CoenGoedhart1 @.***> wrote:

— Reply to this email directly, view it on GitHub https://github.com/dpwe/audfprint/issues/92, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGZUPF3NCCSRY4BQKK64TWG7XRFANCNFSM6AAAAAARYRCJOY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Hi, thanks for responding. I did some tests. having the same query and database on both windows and linux. I tried with the original mp4 files, afpk files (the peaks) and the precomputed afpt files. On windows the mp4 query finds significantly more matches with the mp4 files than the aftp and afpk files. both afpk and afpt outputs are identical on windows and linux. Linux finds also siginificantly more matches with the mp4 comparing to aftp and afpk. However linux mp4 finds less matches than windows mp4. On both machines i installed the newest ffmpeg available. My goal is to find the same exact matches on my linux system as the matches i found on windows using the mp4 files.

"MP3 decoders (even different versions of mpg123) can differ in their net delay, and an identically-timed query will get many more hits than a random time alignment."

can i conclude from this that a possible solution could be to build up the entire database on the linux system since creating the database on a different platform could interfere the delay?

That's puzzling, but I think your results point to differences in the audio codec on the different platforms.

If you're querying with the originals, your very-high matches may be illusory: If the reference and query are the exact same audio (through the same codec) or an exact prefix, then all the hashes will match - something that will never happen with a real, independent query. So I wouldn't get too hung up on those numbers. If the query is actually a separate audio, my guess would be the match count would be equivalent (on average, though perhaps not identical) on both platforms. I wouldn't expect a significant difference between which platform you built the database on, and I don't think it's a big problem to mix reference items ingested on both platforms.

But I'm not sure, and your empirical results are interesting.

DAn.

On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 @.***> wrote:

Hi, thanks for responding. I did some tests. having the same query and database on both windows and linux. I tried with the original mp4 files, afpk files (the peaks) and the precomputed afpt files. On windows the mp4 query finds significantly more matches with the mp4 files than the aftp and afpk files. both afpk and afpt outputs are identical on windows and linux. Linux finds also siginificantly more matches with the mp4 comparing to aftp and afpk. However linux mp4 finds less matches than windows mp4. On both machines i installed the newest ffmpeg available. My goal is to find the same exact matches on my linux system as the matches i found on windows using the mp4 files.

"MP3 decoders (even different versions of mpg123) can differ in their net delay, and an identically-timed query will get many more hits than a random time alignment."

can i conclude from this that a possible solution could be to build up the entire database on the linux system since creating the database on a different platform could interfere the delay?

— Reply to this email directly, view it on GitHub https://github.com/dpwe/audfprint/issues/92#issuecomment-1305574343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY . You are receiving this because you commented.Message ID: @.***>

Converting the queries to WAV instead of mp3/mp4 (then copying between platforms) should also ensure they get into audfprint as the exact same values, to further confirm that the codec is responsible.

DAn.

On Mon, Nov 7, 2022 at 08:24 Dan Ellis @.***> wrote:

That's puzzling, but I think your results point to differences in the audio codec on the different platforms.

If you're querying with the originals, your very-high matches may be illusory: If the reference and query are the exact same audio (through the same codec) or an exact prefix, then all the hashes will match - something that will never happen with a real, independent query. So I wouldn't get too hung up on those numbers. If the query is actually a separate audio, my guess would be the match count would be equivalent (on average, though perhaps not identical) on both platforms. I wouldn't expect a significant difference between which platform you built the database on, and I don't think it's a big problem to mix reference items ingested on both platforms.

But I'm not sure, and your empirical results are interesting.

DAn.

On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 @.***> wrote:

Hi, thanks for responding. I did some tests. having the same query and database on both windows and linux. I tried with the original mp4 files, afpk files (the peaks) and the precomputed afpt files. On windows the mp4 query finds significantly more matches with the mp4 files than the aftp and afpk files. both afpk and afpt outputs are identical on windows and linux. Linux finds also siginificantly more matches with the mp4 comparing to aftp and afpk. However linux mp4 finds less matches than windows mp4. On both machines i installed the newest ffmpeg available. My goal is to find the same exact matches on my linux system as the matches i found on windows using the mp4 files.

"MP3 decoders (even different versions of mpg123) can differ in their net delay, and an identically-timed query will get many more hits than a random time alignment."

can i conclude from this that a possible solution could be to build up the entire database on the linux system since creating the database on a different platform could interfere the delay?

— Reply to this email directly, view it on GitHub https://github.com/dpwe/audfprint/issues/92#issuecomment-1305574343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY . You are receiving this because you commented.Message ID: @.***>

I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux, 1 virtual linux docker system. I created a database using the pi and have 585 queries with audio downloaded from a different source. In the database are the original videos and the queries are tweets, so it's not the original files. I found out that it does not matter on which system you create the database. I created one on linux and one on windows. when using the one on the other system results stay consistent. So, adding mp4 files to the database is for all platforms the same. Only the reuslts of the query are different. The docker and pi outputs exactly the same. The windows system finds significantly more matches.

I also tried to converting to wav.

On the windows machine i did the following mpeg command: for %i in (*.mp4) do ffmpeg -i "%i" "%~ni.wav" when querying windows had the same results but linux did far worse then the mp4 files.

On the linux machine i also converted the same mp4 files to wav: for i in .mp4; do ffmpeg -i "$i" "${i%.}.wav"; done transfering to windows and querying again gave the same good results, on linux the same bad results.

I think it can only be ffmpeg right? im not sure how to investigate further

Yes, I think it's the encoding of the queries and differences in the codec on linux/windows. It may be a licensing thing - Windows may have a high-quality, commercial decoder, but linux may be limited to an inferior open-source one. And it might be different for the queries (from tweets) but the same for the reference items because of a different codec being used for the audio from the two sources.

One way to debug further would be to duplicate the query decoding being performed by audfprint, then look closely at the debug output from ffmpeg on each platform to see what library it reports using.

It should just be "ffmpeg -i -f s16le -ac 1 -ar 11025 out.pcm". For example, on my machine I get:

@.***:~/Downloads$ ffmpeg -i solo.mp3 -f s16le -ac 1 -ar 11025 out.pcm

built with Apple clang version 14.0.0 (clang-1400.0.29.102)

configuration: --prefix=/usr/local/Cellar/ffmpeg/5.1.2 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox

libavutil 57. 28.100 / 57. 28.100

libavcodec 59. 37.100 / 59. 37.100

libavformat 59. 27.100 / 59. 27.100

libavdevice 59. 7.100 / 59. 7.100

libavfilter 8. 44.100 / 8. 44.100

libswscale 6. 7.100 / 6. 7.100

libswresample 4. 7.100 / 4. 7.100

libpostproc 56. 6.100 / 56. 6.100

Input #0, mp3, from 'solo.mp3':

Metadata:

encoder         : Lavf56.15.102

Duration: 00:00:14.86, start: 0.025057, bitrate: 64 kb/s

Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s

Stream mapping:

Stream #0:0 -> #0:0 (mp3 (mp3float) -> pcm_s16le (native))

Press [q] to stop, [?] for help

Output #0, s16le, to 'out.pcm':

Metadata:

encoder         : Lavf59.27.100

Stream #0:0: Audio: pcm_s16le, 11025 Hz, mono, s16, 176 kb/s

Metadata:

  encoder         : Lavc59.37.100 pcm_s16le

size= 320kB time=00:00:14.83 bitrate= 176.4kbits/s speed=1.02e+03x

video:0kB audio:320kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

I'm actually not sure how to pick out the mp3 decoder there, but it would be interesting to compare the results for running on Windows and Linux anyway.

DAn.

On Mon, Nov 7, 2022 at 4:15 PM CoenGoedhart1 @.***> wrote:

I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux, 1 virtual linux docker system. I created a database using the pi and have 585 queries with audio downloaded from a different source. In the database are the original videos and the queries are tweets, so it's not the original files. I found out that it does not matter on which system you create the database. I created one on linux and one on windows. when using the one on the other system results stay consistent. So, adding mp4 files to the database is for all platforms the same. Only the reuslts of the query are different. The docker and pi outputs exactly the same. The windows system finds significantly more matches.

I also tried to converting to wav.

On the windows machine i did the following mpeg command: for %i in (*.mp4) do ffmpeg -i "%i" "%~ni.wav" when querying windows had the same results but linux did far worse then the mp4 files.

On the linux machine i also converted the same mp4 files to wav: for i in .mp4; do ffmpeg -i "$i" "${i%.}.wav"; done transfering to windows and querying again gave the same good results, on linux the same bad results.

I think it can only be ffmpeg right? im not sure how to investigate further

— Reply to this email directly, view it on GitHub https://github.com/dpwe/audfprint/issues/92#issuecomment-1306201306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGZUKUT7GWGSE2G4TYSK3WHFWPHANCNFSM6AAAAAARYRCJOY . You are receiving this because you commented.Message ID: @.***>

Hi DAn, thank you so much! I did manage to recreate the results of the windows machine on the raspberri pi. Converting the mp4 files to wav with the sample rate of 11025 and having FFMPEG on False on the audio_read.py gave me the exact same results. Im looking into using the same decoder on both platforms but for now i have a workable solution! Again, thnx for your help!

dpwe / audfprint