Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic on non-UTF-8 tags in music file #6

Closed
linkmauve opened this issue Jan 29, 2020 · 1 comment · Fixed by #12
Closed

Panic on non-UTF-8 tags in music file #6

linkmauve opened this issue Jan 29, 2020 · 1 comment · Fixed by #12

Comments

@linkmauve
Copy link

I have a music file I can’t modify, which contains SHIFT_JIS-encoded tags (it’s a Wave file containing INAM=東方紅魔郷).

What would be your preferred way to handle this issue? Asking the user to provide the encoding, guessing it, or even to ignore any non-UTF-8 tag and act as if it wasn’t present?

I personally don’t need the tags, but other users might.

Here is the full traceback:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error { valid_up_to: 0, error_len: Some(1) }', /home/linkmauve/.cargo/registry/src/github.com-1ecc6299db9ec823/ears-0.7.0/src/sndfile.rs:383:17
stack backtrace:
r   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1052
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:472
  11: rust_begin_unwind
             at src/libstd/panicking.rs:380
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  13: core::option::expect_none_failed
             at src/libcore/option.rs:1199
  14: core::result::Result<T,E>::unwrap
             at /rustc/c2d141df59703393c0c683abc259f9a8c3be041a/src/libcore/result.rs:963
  15: ears::sndfile::SndFile::get_string
             at /home/linkmauve/.cargo/registry/src/github.com-1ecc6299db9ec823/ears-0.7.0/src/sndfile.rs:383
  16: ears::audio_tags::get_sound_tags
             at /home/linkmauve/.cargo/registry/src/github.com-1ecc6299db9ec823/ears-0.7.0/src/audio_tags.rs:84
  17: ears::music::Music::new
             at /home/linkmauve/.cargo/registry/src/github.com-1ecc6299db9ec823/ears-0.7.0/src/music.rs:132
  18: menu::main
             at examples/menu.rs:119
  19: std::rt::lang_start::{{closure}}
             at /rustc/c2d141df59703393c0c683abc259f9a8c3be041a/src/libstd/rt.rs:67
  20: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  21: std::panicking::try::do_call
             at src/libstd/panicking.rs:305
  22: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:86
  23: std::panicking::try
             at src/libstd/panicking.rs:281
  24: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  25: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  26: std::rt::lang_start
             at /rustc/c2d141df59703393c0c683abc259f9a8c3be041a/src/libstd/rt.rs:67
  27: main
  28: __libc_start_main
  29: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
@nickbrowne
Copy link
Owner

Ah that's definitely not ideal...

I think for now treating non-UTF-8 tags as empty is fine, and a lot better than a panic. If someone really needs to read non-UTF-8 tags then we can possibly add something more elaborate in the future.

linkmauve added a commit to linkmauve/ears that referenced this issue Feb 10, 2020
This prevents a panic when opening a file which contains non-UTF-8 tags,
but still prevents users from accessing them.

In the future it might be useful to provide an API giving the raw bytes
if the user wants to try guessing it, or maybe even add an (optional)
encoding crate dependency for formats which declare their encoding.

Fixes nickbrowne#6.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants